Perché una sola volta le password che utilizzano la catena hash annidata non vengono utilizzate?

Il metodo che descrivi è in effetti un classico algoritmo per le password monouso, ma presenta alcuni svantaggi:

• È buono solo per le password N , dove N deve essere scelto al momento dell'inizializzazione.
• Il client deve invocare la funzione hash R volte, dove R è il numero di password rimanenti nella catena, cioè inizialmente R = N . Questo limita la dimensione di N , altrimenti il costo diventa insopportabile per il sistema client.
• Il server deve conservare uno stato, che è l'ultima password riuscita o un contatore. Il contatore ha il problema che il costo sul server diventa proporzionale al numero della password utilizzata: se l'utente ha utilizzato 1000 password, il server deve richiamare la funzione hash 1000 volte per convalidare la password successiva. D'altra parte, il salvataggio dell'ultima password funziona solo se l'ultima password è l'output hash complete , non un sottoinsieme derivato, il che rende le password monouso molto voluminose, difficili da scrivere (si pensi 20 + caratteri casuali ...).

Per le password monouso, la pratica comune è utilizzare HOTP , che utilizza un contatore su entrambi i lati (client e server) e una sola chiamata HMAC . Si basa anche sulla funzione di hash sottostante che è sicura, ma lo fa in un modo molto più facile da usare, evitando i problemi sopra descritti.

Riepilogo: il metodo che descrivi non viene utilizzato perché sono noti metodi molto migliori - non che siano più sicuri , ma inducono un sovraccarico molto più basso sul client , il server e l'utente umano.

Quello che stai descrivendo sembra vagamente simile negli obiettivi dello schema di password monouso, HOTP .

Tuttavia, dopo molte migliaia di accessi, il mio tentativo di accesso sotto il tuo schema consuma più tempo della CPU del primo accesso che ho tentato. Con HOTP, il tempo per tentare l'accesso è costante.

È anche il caso con questo schema che non posso proteggere il segreto sul lato server nello stesso modo in cui posso con una password (cioè utilizzando un KDF), quindi, una violazione sul lato server garantirà l'accesso a tutti i segreti dell'utente immediatamente, consentendo all'aggressore di impersonare impunemente tutti gli utenti.

Qualsiasi attaccante che conduce un uomo nell'attacco centrale e trova il valore OTP x_n può quindi calcolare anche tutti i futuri x_i in modo tale che i > n semplicemente usando F su x_i

Questo è un grosso problema se è probabile che il segreto venga utilizzato da più siti (ad esempio se vengono utilizzati token hardware costosi o l'utente deve ricordare il segreto)

In primo luogo, il sistema è complicato e presenta altri problemi: l'utente deve ricordare quante volte ha effettuato l'accesso? Se no, chi lo fa? Non è il suo browser, dovrebbe essere in grado di accedere da qualsiasi luogo.

In secondo luogo, qualsiasi forma di crittografia lato client nelle connessioni HTTP è inutile . Un uomo nel mezzo può facilmente modificare il javascript, rimuovere la funzione di hashing e ottenere la password in chiaro. Quasi tutti gli attacchi MITM hanno il possibilità di modificare i dati (non solo leggerli), quindi questa è sempre un'opzione.

Alla fine, se vuoi rendere il tuo modulo di accesso più sicuro, usa semplicemente HTTPS. La crittografia lato client non aggiunge molta sicurezza (se non aggiunge affatto qualsiasi sicurezza) e non vale gli altri problemi che introduce.

Stavo cercando una risposta alla domanda "perché la catena di hash reverse di Lamport viene dimenticata a favore di schemi condivisi come il TOTP".

È chiaro che alle persone non piace tenere traccia dello stato, ecco perché l'autenticazione basata sul tempo ha vinto.

Ma ora i cicli di memoria e CPU sono più economici che mai, quindi l'hardware incorporato tipico ha abbastanza per mantenere la catena inversa necessaria per la sua piena durata fisica.

Si scopre che non sono l'unico a pensarci! Tutto ciò che ho trovato è stato già proposto nel documento T / Key:

link