Quali sono gli svantaggi dell'utilizzo della condivisione segreta di Shamir per implementare uno schema di password parziale?

Question

Quali sono gli svantaggi dell'utilizzo della condivisione segreta di Shamir per implementare uno schema di password parziale?

#1 da (2 voti)

1

Supponiamo di voler implementare uno schema di password parziale, in cui l'utente effettua l'autenticazione utilizzando due password: una una password normale, l'altra è parziale, dove ha solo bisogno di digitare i tre caratteri selezionati di quella password:

Ho chiesto in precedenza sull'implementazione di questo ed è ovvio che approcci semplici come l'hashing di singoli caratteri falliscono completamente . Supponiamo anche di non aver implementato un modulo di autenticazione hardware che memorizzerà la password e ti fornirà una risposta corretta / errata per il tuo input.

Un altro approccio potenziale sta usando Condivisione segreta di Samir , come descritto nei dettagli qui per quanto riguarda l'idea di password parziali.

Approssimativamente, stiamo fornendo la possibilità di recuperare una password segreta (o il suo hash, che è meglio) fornendo diciamo 3 blocchi su 8 di dati.

Questo schema è protetto contro la forza bruta da un utente malintenzionato che ottiene l'accesso al database e, per sicurezza, intendo sicuro almeno nella stessa misura di un database di password tradizionali salate e hash?

authentication passwords brute-force

posta K48 26.10.2018 - 03:53

fonte

1 risposta

Leggi altre domande sui tag authentication passwords brute-force

Cambia il checksum di un file dopo che è stato firmato digitalmente? Nome community SNMP predefinito o accettabile: pubblico

score 2 · Accepted Answer

The fonte che citi in realtà indica già i problemi, anche se in realtà li considera come problemi ma come vantaggio. Per citare:

Pros and Cons
The highlights of this solution are:
...
5. Faster to compute - verification is several multiplications of 32 bit numbers that is much much faster than computing a hash value.

L'attacco che stai tentando di impedire è che l'aggressore possa indovinare correttamente, a condizione che l'attaccante conosca le informazioni segrete archiviate nel database.

Nel tuo esempio hai un segreto con 10 caratteri alfanumerici in cui l'autore dell'attacco deve indovinare uno specifico 3 caratteri. Ciò significa che sono necessarie 36 supposizioni ³ quando sono consentiti solo caratteri maiuscoli o 72 ³ con caratteri minuscoli. Dato che il controllo è molto molto veloce, l'attaccante può trovare rapidamente questi valori (vale a dire probabile in tempo reale) se il segreto memorizzato nel database è noto.

Se l'attaccante deve scegliere più di 3 personaggi, diventa più difficile da fare in tempo reale, ma può essere facilmente precalcolato. Se sono necessari 5 caratteri su 10 di 10 * 9 * 8 * 7 * 6 / (2 * 3 * 4 * 5) le possibili "maschere" per l'inserimento dei caratteri devono essere precalcolate e ognuna ha al massimo 36 ⁵ (o 72 ⁵) valori possibili, ovvero al massimo 10 * 9 * 8 * 7 * 6 / (5 * 4 * 3 * 2) * 72 ⁵ devono essere fatti calcoli molto veloci. Supponendo che in un secondo si possano effettuare 10000 calcoli, un giorno l'attaccante porterebbe l'attaccante se possiede una botnet di circa 600 macchine - il che non è irragionevole. E probabilmente potrebbe essere ottimizzato. Con 4 caratteri su 10, sarebbero necessari solo 6 macchine per un giorno e con 3 su 10 una macchina singola potrebbe fare ciò in meno di 1,5 ore.

Si noti che questa stima presuppone anche un segreto casuale. Se si tratta di un segreto scelto dall'utente, la situazione peggiora notevolmente. Ma, se l'utente non può scegliere il segreto, probabilmente ha bisogno di scrivere il segreto casuale da qualche parte - sconfiggendo la tua idea originale perché questo segreto aggiuntivo dovrebbe essere dato (ad esempio, evitare la navigazione a spalla e l'archiviazione nei gestori di password) in molti casi.