Cosa considerare quando si genera codice casuale come parte dell'autenticazione a due fattori?

Riepilogo. No, quel codice non sembra sicuro. Non ha abbastanza entropia che sarà imprevedibile per l'avversario. Non vorrei riutilizzare quel codice.

Il modo giusto per farlo. Per generare un codice casuale, ti suggerisco di leggere il numero desiderato di bit da /dev/urandom . Questo è un codice monouso e deve essere casuale, non diagnosticabile e crittograficamente strong. Questo è esattamente ciò che fornisce /dev/urandom . Il produttore del sistema operativo ha già elaborato come farlo in modo sicuro, dopo un'attenta analisi, e tale approccio è stato controllato da esperti di sicurezza. Ti suggerisco di riutilizzare semplicemente il loro lavoro esistente.

Analisi di second_factor_regenerate_token . Non so se sto capendo il codice correttamente, ma sembra che non abbia abbastanza entropia. Dispone del nome utente dell'utente, della password dell'utente, delle intestazioni HTTP e dell'ora corrente. Non è abbastanza entropia.

Ricorda che lo scopo di un secondo fattore è quello di impedire che individui non autorizzati che in qualche modo sono venuti a conoscenza del nome utente e della password dell'utente dall'accedere al sistema. (Se l'individuo non autorizzato non conosce il nome utente e la password dell'utente, non è necessario un secondo fattore, il primo fattore li blocca già.) Quindi la nostra analisi dovrebbe partire dal presupposto che l'utente malintenzionato conosce il nome utente e la password dell'utente .

Una volta presa questa ipotesi, l'unica entropia rimanente viene dall'ora corrente e dalle intestazioni HTTP. Il tempo sicuramente non ha abbastanza entropia: sarà conosciuto, o quasi noto, all'attaccante (probabilmente fuori da pochi secondi, a causa della sincronizzazione oraria imperfetta, ma l'attaccante può semplicemente provare tutte le possibilità). Non so quanta entropia sarà nelle intestazioni HTTP, ma non suona come una solida base per la sicurezza.

Pertanto, sulla base della mia interpretazione di second_factor_regenerate_token , supponendo che io capisca correttamente come funziona il codice, non penso che rappresenti una buona ingegneria della sicurezza. Non vorrei riutilizzare quel codice.

Guarda le motivazioni alla base di HOTP , che è stato progettato per questo tipo di applicazione.

Alcune delle funzioni desiderate sono:

• password singole generate come necessario (in questo caso, dopo che l'utente ha completato l'autenticazione principale)

• fattibile da inviare, visualizzare sul telefono dell'utente e inserire

• fattibile per verificare in situazioni come richieste multiple di nuove password, mandati non ordinati o saltati

• abbastanza alta entropia (non basata su informazioni conoscibili come il nome utente o la password del primo fattore, non è ipotizzabile se sono note password precedenti)

Con HOTP, si memorizzano una chiave segreta e un contatore per utente, nessuno dei quali viene inviato. Per generare una password monouso, si hash la chiave e il contatore, si invia l'hash e si incrementa il contatore. Per verificare una password, hai cancellato la chiave e un intervallo di contatori e confrontarli.

Potresti ottenere il tuo personale seguendo queste linee, ma HOTP è uno standard. Puoi trovare le implementazioni revisionate per il tuo sistema e puoi trovare l'aiuto della community per decidere se è adatto a te.