La correzione automatica degli errori di battitura nelle password è sicura?

Full disclosure: sono uno degli autori del documento.

Un sistema di controllo della password esatto memorizza uno standard salato, hash lento da calcolare della password. Quando una password, come password123, è registrato con il servizio di autenticazione, un sale casuale "sa" è selezionato (questo dovrebbe essere 16 o più byte casuali) e a viene applicata la funzione hash a calcolo lento H: sa (password123). Il risultato, chiamalo h, è memorizzato in un database insieme a sa sale. Come menzionato, si dovrebbe scegliere H per essere lento (10s o 100s di millisecondi per calcolare). Le buone scelte sono argon2, scrypt o PBKDF2, opportunamente configurate.

Quando un utente in seguito tenta l'accesso, se digita la sua password l'hash viene ricalcolato e verificato rispetto al valore memorizzato. Nell'esempio sopra, se l'utente invia password123, si ricalcola (di nuovo lentamente) H (sa, password123) e controlla il risultato --- corrisponde al precedente l'h calcolata e l'accesso possono essere consentiti. Qualsiasi deviazione nella password inviata da quella precedentemente registrata restituisce un valore hash completamente diverso e l'accesso non riesce.

La nostra idea è semplice: se il primo controllo fallisce, il sistema può anche applicare un numero limitato di funzioni "correttore" alla password inviata, e quindi applicare l'algoritmo di hashing al risultato. Ad esempio potremmo risolvere una funzione correttore tappi F_caps che prende come input una password e restituisce la password con la maiuscola di tutte le lettere modificate: F_caps (PASSWORD123) = password123 e F_caps (pAsSwOrD123) = PaSsWoRd123. Potremmo anche correggere un correttore di capitalizzazione di prima lettera: F_prima (Password123) = password123 e F_prima (pASSWORD123) = PASSWORD123. Nota che questi sono semplici da implementare.

Quindi, per fare il controllo degli errori di battitura si dovrebbe applicare la seguente logica una sessione saltata in precedenza, una coppia di hash (sa, h) e una password inserita pw

Se H (sa, pw) = h o H (sa, F_caps (pw)) = h o H (sa, F_prima (pw)) = h allora consentire l'accesso

Ad esempio, se una PASSWORD123 è stata inviata, i controlli sarebbero attivi PASSWORD123, password123 e PASSWORD123, con il secondo controllo riuscendo.

Alcuni punti:

1) L'efficacia degli attacchi di forza bruta offline è esattamente la stessa di prima. Perché? Perché archiviamo solo sa, h. L'attaccante, data sa, h, volontà impara solo la password tramite un attacco a forza bruta che tenta il corretto password, nel nostro esempio password123. Non c'è perdita di sicurezza qui come non abbiamo cambiato il modo in cui H è calcolato.

2) C'è un cambiamento trascurabile nella sicurezza contro le supposizioni remote attacchi. Lo dimostriamo attraverso analisi approfondite nel documento, ma bolle giù al fatto che nel mondo reale la strategia migliore è presentare il molto probabilmente password fino ad un certo limite (ad esempio, molti siti bloccano un account dopo 10 tentativi falliti). I controlli extra eseguiti a causa di errori di battitura la correzione può aiutare l'aggressore a diventare un po 'più fortunato, ma lo dimostriamo che è essenzialmente trascurabile. Se uno è preoccupato, lo diamo tecniche che lo riducono ulteriormente.

3) La tolleranza di battitura aumenterà l'utilizzo della CPU per il server di login (e probabilmente carico di memoria, quando H è un hash hard di memoria come scrypt o Argon2). Ciò è dovuto alle invocazioni extra lente di elaborazione di H. In Praticare questo non sembra essere troppo costoso come ci si potrebbe aspettare (3x nel nostro esempio sopra) perché comunque gli utenti sarebbero finiti invio di nuovo dopo il rifiuto e si paga il prezzo per ogni tentativo.

4) Non suggeriamo di consentire errori di battitura arbitrari. Questo non è nemmeno possibile attualmente, poiché richiederebbe di ricalcolare H un numero proibitivo di volte (ricorda che è lento!), e comunque questo sarebbe insicuro. Uno deve scegliere con cura quali errori di battitura consentire in base a un'analisi di principio. Noi credo che i due correttori di cui sopra, caps lock e prima lettera la capitalizzazione, sono una scelta impropria per l'implementazione sicura, oltre a ciò inizia a diventare più sfumato.

Abbiamo aggiunto una FAQ che fornisce informazioni aggiuntive: link

Modifica: questa risposta non è corretta, vedere la risposta più votata. Nell'appendice hanno fatto riferimento a "schizzi sicuri" ma, leggendo la carta più vicino, vedo che non consigliano questo metodo:

In theory a secure sketch [17] could be used to correct some typos in the server side. However, the proven bounds for existing constructions are too weak to provide meaningful protection for our setting (in which entropy is quite low).

Hanno già riconosciuto i miei punti che ho scritto qui e ho respinto questa idea. Ho completamente perso quella lettura del giornale la prima volta.

-

Nonostante il fatto che il documento di ricerca sembri altamente credibile, io stesso non sono d'accordo con le loro conclusioni. Sebbene i loro calcoli siano validi, le loro ipotesi non tengono conto degli scenari di attacco del mondo reale né tengono conto di come le persone selezionano le password.

In sostanza quello che stanno dicendo è che ci sono alcuni errori comuni, come avere il Capslock abilitato, non capitalizzare la prima lettera, aggiungere o rimuovere un personaggio, o premere un tasto adiacente sulla tastiera. La loro soluzione proposta consente di ignorare tutti questi errori apparentemente minori, in modo che il sistema accetti la password abbastanza vicino.

Anche se questo è un enorme miglioramento nell'usabilità (tutti facciamo errori di battitura quando si inseriscono le password), il compromesso in termini di sicurezza è molto maggiore di quello che riconosce. Parte del problema è che non si rivolgono online (accesso a un sito web live) o offline (ottenendo il database hash e copiandoli sul tuo computer). Con un attacco offline in cui l'attaccante può potenzialmente forzare la fatturazione di miliardi di password al secondo, le password fuzzy fallirebbero notevolmente.

Supponiamo, ad esempio, che un hacker ottenga un database di un milione di password e tenti un attacco di dizionario ibrido su di essi. Normalmente, il software di cracking della password prenderà una parola come "password" e proverai tutte le permutazioni di ciò, tra cui Password, pAssword, PAssword, password1, password !, ecc. Dovendo provare centinaia di permutazioni di ogni singola parola del dizionario è ciò che rende il cracking delle password richiede molto tempo.

Nel caso di password fuzzy, quasi tutte quelle permutazioni funzionerebbero come password valide. Dillo semplicemente cerca "password" contro l'intero set di un milione di password. L'hacker otterrebbe corrispondenze corrette per ogni account di quella parola e ogni singola permutazione. Il grosso problema qui è che molte persone rafforzano le loro password cambiando una lettera, usando la maiuscola casuale, aggiungendo un numero o la punteggiatura alla fine, ecc. Le password sfocate rendono tutte quelle tecniche inefficaci.

È importante che costringiamo un attaccante a provare ogni singola permutazione per guadagnare anche un millesimo di secondo per ogni tentativo. Questo è precisamente il motivo per cui utilizziamo centinaia o migliaia di cicli di hash con algoritmi come PBKDF2. Ogni bit di lavoro che il software di cracking della password ha a che fare con ogni password funziona a nostro vantaggio.

Nel documento stanno considerando l'intero spazio della password e calcolano correttamente che il controllo fuzzy non riduce in modo significativo il numero di password possibili che un utente malintenzionato deve sfruttare. Il problema è che le password non sono distribuite uniformemente in questo spazio potenziale, ma piuttosto raggruppate attorno allo spazio relativamente piccolo che consiste nelle parole del dizionario. Se si tiene conto di ciò, la perdita di sicurezza è significativa.

Per mettere questo in prospettiva, se si prende la superficie di tutti gli Stati Uniti (3,8 milioni di miglia quadrate) per rappresentare tutte le possibili password che si potrebbero scegliere, le password effettive che tutti usano si inseriscono in un'area di circa 5 piedi quadrati . Le password sfocate in uno spazio così piccolo sarebbero un disastro.

L'idea funzionerebbe bene su sistemi con sicurezza casuale e in cui l'usabilità è importante. Potrebbe anche essere accettabile se utilizzato in combinazione con più fattori di autenticazione come un token hardware o un sensore biometrico. Ma, per tutto il resto, la tecnica semplicemente non è abbastanza sicura.

Qui ci sono due scenari di attacco plausibili:

1. cracking offline
2. Cracking online

Nella situazione di cracking offline, la carta descrive ancora che devono essere applicati i principi crittografici forti. Ciò significa che non esiste una logica fuzzy. C'è solo il lavoro richiesto per calcolare l'hash finale conoscendo il sale e indovinando agli input. In questo scenario non esiste alcun reale vantaggio o svantaggio dei metodi della carta.

Nella situazione di cracking online, quando l'utente malintenzionato indovina a caso le password contro una fonte online, c'è un compromesso tra usabilità e sicurezza. In sostanza, ogni tentativo vale diversi (a seconda dell'algoritmo di correzione utilizzato e della quantità di correzione possibile). Il trade qui sembra teoricamente minimo in uno scenario di account singolo.

Tuttavia , all'interno di un realistico modello di minaccia online gli attacchi si verificano su una scala molto più grande . Le botnet tentano attacchi di password comuni nella speranza che alcuni siano corretti per puro caso. Ciò che questo articolo descrive è qualcosa che, su larga scala, aumenterebbe il rischio complessivo di compromissione dell'account.

In definitiva si tratta del compromesso dell'usabilità della sicurezza. In questa situazione non sarei incline a impostare una politica del genere su qualsiasi scala in quanto potrebbe effettivamente moltiplicare l'efficacia dei tentativi malevoli.

Secondo il giornale, c'è un impatto sulla sicurezza zero nel caso di attacchi brute-force offline. Questo perché non vi è alcuna modifica al database contenente le password hash. Il controllo online degli errori di battitura utilizza "controllo esatto", ovvero corrispondenza con un hash memorizzato, come subroutine.