Perché i sali per le password di hashing devono essere globalmente unici, non solo sistema / sito-unico?

11

Stavo leggendo una risposta di Terry Chia a un'altra domanda sui requisiti per un sale, in cui lui / lei (tra gli altri) ha specificato che i sali devono essere globalmente unici, ma non entrare nel dettaglio sul perché. Questo è stato definito come "non solo unico nel contesto del tuo database, ma unico nel contesto di ogni singolo database là fuori". Ad esempio, ho utilizzato un indirizzo email come sale per il mio sito web / database di esperimenti sandbox. Questi potrebbero certamente essere utilizzati come sali su altri siti web.

Non ha senso per me perché, a quanto ho capito, lo scopo del sale è quello di garantire che "spezzare più password compromesse insieme non dovrebbe essere più facile che scoppiarle separatamente" (Ilmari Karonen, più in basso sullo stesso post). A meno che non mi sbagli, questo vincolo è soddisfatto finché i miei sali sono unici nel mio database.

Sono ulteriormente confuso perché generare dei sali globalmente unici mi sembra impossibile da controllare. Come potrei essere in grado di garantire che nessuno dei miei sali sia mai stato usato sul sito di qualcun altro, con milioni di siti là fuori? Per essere onesti, non ho ancora studiato come generare sali casuali; forse l'idea è che sono creati da un pool abbastanza grande che anche considerando il numero di siti là fuori, i duplicati generati per database separati sono molto improbabili?

Sono decisamente prevenuto nell'usare un indirizzo email come mio sale, dal momento che si tratta di un piccolo passo di lavoro, ma dato il numero di persone che sembrano non essere d'accordo con questo approccio, riconosco che probabilmente ho torto. E poi, voglio sapere di più sul perché ho torto perché non ha ancora un senso.

    
posta Char Star 29.11.2017 - 06:04
fonte

3 risposte

13

L'obiettivo della salatura è resistenza alla precomputazione .

Anche se non puoi garantire che un sale sia globalmente unico, puoi (come hai detto tu) generare sali di dimensioni sufficienti da rendere impossibile generare un tabella arcobaleno in anticipo (rendendoli" abbastanza unici ").

Più in generale, se ti stai chiedendo come creare un sale, sembra che stia rotolando il tuo metodo di hashing, che può essere educativo ma generalmente non consigliato.

Usa invece un hash esistente (come PBDKF2 o bcrypt) (o anche meglio, come CBHacking suggerisce giustamente nei commenti, scrypt o Argon2). Non solo erediterete automaticamente i loro metodi di salatura esistenti (che sono abbastanza sufficienti), ma la vostra sperimentazione sarà allineata con le migliori pratiche di archiviazione delle password ... che probabilmente sarebbe una pratica migliore.

Aggiornamento 2018-04-03 : Steve Thomas (sc00bz) rappresenta un buon punto qui che Argon2 e scrypt sono in realtà peggiori per il defender quando vengono utilizzati a velocità generalmente considerate compatibili con l'autenticazione su scala (< 0,1 secondi), mentre sono migliori per il defender per velocità compatibili con la crittografia dei singoli file (da 1 a 5 secondi ). (Ciò significa che il divario da 0,1 secondi a 1 secondo è probabilmente interessante e porta test per il tuo ambiente specifico). In altre parole, la sua affermazione è che se si tenta di sintonizzare Argon2 o scrypt con velocità di < 0.1s, i risultati sono meno resistenti al cracking rispetto a bcrypt a quelle velocità.

Nella stessa discussione, Aaron Toponce anche fa un ottimo suggerimento per lavorare intorno alla lunghezza di bcrypt (72 caratteri max) e limitazioni di pre-hashing, utilizzando bcrypt(base64(sha-256(password))) . (Vedi anche la risposta simile di Thomas Pornin qui ). Anche la base64 è necessaria è interessante - non lasciarlo fuori.

Quindi, se il tuo caso d'uso è un'autenticazione scalabile, resistente a fessurazioni con esperienza di autenticazione rapida, bcrypt(base64(sha-256(password))) è probabilmente un buon approccio. (E sarà necessario adattare il fattore di lavoro di bcrypt al valore più alto che si adatta alla finestra della velocità di autenticazione). Se gli utenti possono tollerare l'attesa di un secondo o più per l'autenticazione, Argon2i o scrypt potrebbero essere migliori. E nota che le prestazioni relative si sposteranno nel tempo, man mano che le capacità hardware miglioreranno, quindi aumentare il fattore di lavoro bcrypt ogni X mesi per i nuovi hash (come fa Dropbox) consentirebbe all'approccio di adattarsi alle funzionalità future nel tempo.

    
risposta data 29.11.2017 - 06:29
fonte
4

Non è vantaggioso utilizzare l'indirizzo e-mail anziché generare un valore casuale. Devi comunque memorizzarlo come il sale casuale, altrimenti l'utente non può mai cambiare l'indirizzo e-mail.

L'unicità globale non è un requisito, non è necessario garantire l'unicità, ma quanto più unici sono globalmente i sali, tanto meglio. Le possibili combinazioni per un sale a 128 bit (BCrypt) sono 3E38. Anche se generi 1000 sali / sec, ci si aspetterebbe circa 6/8 anni di attesa per una probabilità del 50% di duplicati.

Come Royce ha già menzionato, gli algoritmi di oggi generano già il sale per te e lo memorizzano in chiaro nella stringa hash risultante, quindi non c'è bisogno di una gestione speciale nel database (solo 1 campo per l'hash).

Quando si utilizzano gli indirizzi e-mail, un utente malintenzionato potrebbe calcolare le tabelle arcobaleno per determinate e-mail di interesse.

Mentre gli svantaggi non sono fatali nella pratica, semplicemente non ci sono vantaggi, quindi perché dovresti scegliere un metodo più complicato e meno sicuro per generare il sale? Usa una moderna funzione di hash della password e sei bravo.

    
risposta data 29.11.2017 - 11:28
fonte
0

Questo argomento diventa molto più chiaro se invece di dire che i sali "hanno bisogno" di essere globalmente unici, osserviamo invece che la sicurezza ottimale si ottiene se lo sono.

Considera il seguente modello di attacco semplicistico: un utente malintenzionato ottiene n voci di password e hanno le risorse per eseguire il test di m in totale. Ora considera i casi estremi:

  • Se le password non sono salde (o tutte hanno lo stesso sale), allora ciascuno dei calcoli di m può essere verificato rispetto a tutte le voci n . Il che significa che riescono a testare m * n ipotesi utente / password.
  • Se tutte le password sono salate con sali univoci, allora ciascuno dei calcoli di m può essere verificato solo con 1 voce. Ciò significa che possono solo testare m ipotesi utente / password.

Se alcuni ma non tutti i sali sono duplicati, l'attaccante ottiene qualcosa nel mezzo, proporzionale al numero di sali distinti. Ma questo non significa che la salatura fallisca in modo catastrofico sulla duplicazione salina, ma piuttosto che la sua efficacia degeneri linearmente.

Dal momento che i sali casuali sufficientemente grandi sono generalmente facili da implementare e raggiungono un unicità globale con tutte le possibilità, a parte trascurabili, contro, c'è davvero poca ragione per non andare in quella direzione.

I sali casuali hanno un'altra proprietà importante, che sottolinea la risposta di martinstoeckli alla domanda che link : l'attaccante non può prevedere in anticipo quali sali userete. La tua proposta di utilizzare gli indirizzi email non soddisfa questo criterio.

    
risposta data 03.04.2018 - 23:44
fonte

Leggi altre domande sui tag