Password monouso con reverse engineering per sistemi di autenticazione a due fattori

Se l'algoritmo di generazione OTP è buono (e HOTP è buono):

• il miglior attacco quando si conosce la una password generata, e cercando di indovinare il prossimo, dovrebbe essere una ricerca esauriente sulla chiave (e la ricerca esaustiva non è fattibile se la chiave è abbastanza grande, ad esempio un Chiave a 128 bit);
• conoscere molte password precedenti non dovrebbe dare alcun ulteriore vantaggio all'attaccante.

L'Appendice A di RFC 4226 descrive l'analisi della sicurezza di HOTP; al suo centro sta l'ipotesi che HMAC / SHA-1 sia una funzione casuale selezionata dalla chiave:

To be more precise, let Maps(c,n) denote the set of all functions mapping from {0,1}^c to {0,1}^n. The idealized algorithm has key space Maps(c,n), so that a "key" for such an algorithm is a function h from {0,1}^c to {0,1}^n. We imagine this key (function) to be drawn at random.

Questo è il oracolo casuale modello. HMAC con una funzione hash sicura, o anche HMAC con una funzione hash leggermente debole come SHA-1, è la migliore approssimazione pratica di un oracolo casuale che i crittografi hanno in serbo.

Per riassumere la prova di sicurezza di HOTP:

• con un oracolo casuale, conosci niente dell'output per un dato input finché non lo provi su quell'input esatto ;
• le password generate sono (derivate da) l'output di HMAC / SHA-1, ritenuto non distinguibile da un oracolo casuale, su un valore contatore;
• quindi, nessuno sa nulla di una password che verrà generata finché il corrispondente valore del contatore non viene effettivamente inserito come input di HMAC / SHA-1, cosa che non si è verificata in precedenza (per le password generate più vecchie) perché è un counter e non "wrap around".

Naturalmente ci sono dettagli su cui fare attenzione, ma gli scrittori di RFC sono noti crittografi e la dimostrazione dettagliata nell'appendice A è chiara e chiara (ed è stata esaminata da molti altri crittografi, che è il vero test di sicurezza) .

Secondo la RFC:

The analysis demonstrates that these final steps introduce a negligible bias, which does not impact the security of the HOTP algorithm, in the sense that the best possible attack against the HOTP function is the brute force attack. Assuming an adversary is able to observe numerous protocol exchanges and collect sequences of successful authentication values. This adversary, trying to build a function F to generate HOTP values based on his observations, will not have a significant advantage over a random guess. The logical conclusion is simply that the best strategy will once again be to perform a brute force attack to enumerate and try all the possible values.

Quindi, secondo l'analisi della sicurezza, non c'è praticamente alcuna differenza se si memorizzano o si ha accesso ai vecchi valori OTP. In pratica non puoi usarli per aumentare le possibilità di trovare un valore OTP corretto.

La sicurezza del generatore di password one-time ovviamente non deve essere indebolita dalla conoscenza delle password precedenti.

Il punto chiave è che l'uso della crittografia simmetrica con una key known only to the token and the validation service ( RFC 4226 ) non ti consente di restringere ciò che chiami possibili semi sotto il spazio di ricerca per la combinazione simmetrica di chiave / algoritmo utilizzata per la crittografia, che a sua volta dovrebbe essere scelta abbastanza grande / sicura per rendere impraticabile un attacco a forza bruta.