Uno schema One Time Password basato su Diceware è valido e sicuro?

Question

Uno schema One Time Password basato su Diceware è valido e sicuro?

#1 da (1 voti)

3

Recentemente ho imparato a conoscere il diceware e stavo pensando a come potrebbe essere usato per creare uno schema di password monouso. Sto pensando che S / KEY sia probabilmente più appropriato, ma un sistema che considera questo sicuro?

Utilizza un generatore di numeri casuali strong per creare un seme iniziale
Genera un nuovo numero casuale da un CSPRNG
Crea una password per diceware dai 15 bit inferiori (per 5 dadi, 18 per 6 dadi, ecc.)
Archivia il seme in modo sicuro

Generare elenchi di password può ovviamente essere fatto purché tu abbia il seme iniziale, e puoi sempre generare nuove password cambiando il seme iniziale. Sembra abbastanza semplice e la lista di parole di diceware è > 3 volte la dimensione di S / KEY che sembra renderla più sicura ... Tuttavia, uno schema così semplice sembra probabilmente insicuro a causa di qualcosa che mi manca. Questo schema è stato studiato prima? È praticabile?

Modifica : ho realizzato che il mio passaggio 3 è difettoso. Abbiamo bisogno di più numeri casuali per estrarre 15 bit per ogni parola prodotta da diceware. In altre parole, abbiamo bisogno di 60 bit per 5 parole e 120 bit per 8 parole. Ma il punto rimane lo stesso.

passwords password-policy

posta apgwoz 20.12.2012 - 05:17

fonte

1 risposta

Leggi altre domande sui tag passwords password-policy

Gli attacchi man-in-the-middle contro i sistemi p2p sono realistici? Categorizzazione dei server di backup nel Toolkit di Scoping PCI aperto

score 1 · Answer 1

Il problema è che un generatore di numeri casuali non è crittograficamente sicuro. Qualcuno potrebbe esaminare la progressione delle password e potenzialmente lavorare all'indietro attraverso l'algoritmo per determinare il seme utilizzato. A questo punto, la tua chiave sarebbe rotta.

Il metodo che descrivi è in realtà molto simile al modo in cui funzionano la maggior parte dei dispositivi token a due fattori. Fondamentalmente, memorizzano una chiave di crittografia in modo sicuro. Quindi utilizzano la chiave di crittografia per crittografare un timestamp basato su un orologio interno. Il server conosce anche la chiave e sa quale dovrebbe essere il valore crittografato. Quindi lo riducono ad un valore che può essere facilmente inserito dall'utente. Se entrambi i valori corrispondono, ti verrà dato l'accesso.

La correzione della deriva per l'orologio del token viene eseguita cercando la deriva lenta e regolando l'offset di tempo per il token sul server. Ad esempio, se inizi a inserire in modo coerente i codici che stanno per essere validi, allora sa che l'orologio sul token è in esecuzione e può adattarsi di conseguenza.

Il server memorizza anche il timestamp utilizzato più di recente e non accetterà alcun codice che lo preceda. (Anche se non verrebbero accettati al di fuori di una finestra di 1 minuto, ma questo è per impedire una riproduzione rapida dopo averlo fatto apparire un codice è stato negato.)