Qual è la lunghezza ottimale per la password utente salt? [chiuso]

128

Ovviamente qualsiasi tipo di sale sarà di grande aiuto durante la salatura e l'hashing della password di un utente. Ci sono delle migliori pratiche per quanto tempo dovrebbe essere il sale? Conserverò il sale nella mia tabella utente, quindi vorrei il miglior compromesso tra dimensioni di archiviazione e sicurezza. È sufficiente un sale casuale di 10 caratteri? O ho bisogno di qualcosa in più?

encryption hash salt

— David
fonte

10

Non ho una raccomandazione sulla lunghezza del sale, ma le risposte che appaiono qui hanno molte cattive informazioni. Il tuo sale dovrebbe sicuramente: - essere casuale - essere per segreto (non un singolo valore memorizzato nell'immagine del programma o nel file di configurazione). Il sale non è un segreto crittografico, quindi memorizzarlo nella tua tabella non è un problema. L'unico scopo di un salt è quello di garantire che quando diverse istanze dello stesso articolo vengono hash (o crittografate) si ottenga un risultato diverso.

— Michael Burr,

2

Per coloro che non sanno cos'è il sale: <a href=" en.wikipedia.org/wiki/Salt_(cryptography)"> Salt (crittografia) </a> su Wikipedia

— David Koelle,

1

O se esiste un rapporto ottimale tra la lunghezza del sale e la lunghezza dell'hash output? Il salt da 8 byte potrebbe essere sufficiente per HMAC-SHA-256, ma non per HMAC-SHA-512.

— Crend King,

1

Il sale crittografico casuale delle stesse dimensioni dell'output della funzione di hashing significa che un attacco "prova tutti i possibili sali" (più un dizionario password) richiede lo stesso sforzo di un attacco "prova tutti i possibili risultati hash" - che è una forza bruta standard . Un salt più breve significa che puoi avere un dizionario salt più un dizionario password come attacco di forza bruta.

— Richard Gadsden,

-1 Certo, non (nemmeno tentare di) rispondere alla domanda.

— user359996

70

Molte di queste risposte sono un po 'fuorvianti e dimostrano una confusione tra sali e chiavi crittografiche. Lo scopo di includere i sali è di modificare la funzione utilizzata per l'hash della password di ciascun utente in modo che ogni hash della password memorizzata debba essere attaccato individualmente. L'unico requisito di sicurezza è che sono univoci per utente, non ci sono vantaggi nell'essere imprevedibili o difficili da indovinare.

I sali devono solo essere abbastanza lunghi da rendere unico il sale di ogni utente. È improbabile che i sali casuali a 64 bit si ripetano anche con un miliardo di utenti registrati, quindi dovrebbe andare bene. Un salt ripetuto singolarmente è un problema di sicurezza relativamente minore, che consente a un utente malintenzionato di cercare due account contemporaneamente, ma nel complesso non accelererà molto la ricerca sull'intero database. Anche i sali a 32 bit sono accettabili per la maggior parte degli scopi, nel peggiore dei casi accelereranno la ricerca di un attaccante di circa il 58%. Il costo per aumentare i sali oltre i 64 bit non è elevato ma non esiste alcun motivo di sicurezza per farlo.

Ci sono alcuni vantaggi nell'utilizzare anche un sale a livello di sito in cima al sale per utente, questo eviterà possibili collisioni con hash di password memorizzati in altri siti e impedirà l'uso di tabelle arcobaleno per scopi generici, anche se anche 32 bit di il sale è sufficiente per trasformare le tavole arcobaleno in un attacco poco pratico.

Ancora più semplice - e gli sviluppatori lo ignorano sempre - se si hanno ID utente o nomi di accesso univoci, questi funzionano perfettamente come un sale. Se lo fai, dovresti aggiungere un salt a livello di sito per assicurarti di non sovrapporsi con gli utenti di un altro sistema che hanno avuto la stessa brillante idea.

— SecurityJoe
fonte

16

C'è un vantaggio nell'imprevedibilità dei sali. Un sale prevedibile potrebbe essere previsto e utilizzato in un attacco di tabella hash. Ad esempio, se il tuo sale è solo l'ID utente, allora una tabella hash alfa semplice abbastanza lunga includerà non solo tutte le password, ma tutte le combinazioni nome utente + password.

— Richard Gadsden,

6

Nota in relazione al tuo ultimo paragrafo, se usi un salt a livello di sito, dovrebbe essere esattamente questo: a livello di sito. Non a livello di applicazione, ovvero ogni nuova istanza che installi l'applicazione dovrebbe generare un nuovo salt a livello di sito. Ad esempio, se Windows utilizzava lo stesso salt su ogni database di autenticazione di Windows, sarebbe utile creare una tabella arcobaleno per quel salt, ma se ogni installazione di Windows generasse un nuovo salt, allora non lo farebbe.

— Richard Gadsden,

5

Il problema non è proprio che il sale deve essere difficile da indovinare. L'attaccante non ha bisogno di indovinare il sale: chiunque abbia accesso all'hash ha già il sale. Il problema è che se i tuoi sali sono molto comuni (come i nomi utente), potrebbero essere gli stessi di quelli di altri siti, ea quel punto l'attaccante ha bisogno di un set molto più piccolo di tavoli arcobaleno per rendere fattibili gli attacchi. Questo è il motivo per cui viene citata l'idea del sale per sito, per evitare questo tipo di collisione con altri siti.

— Nate CK,

3

Nota rapida: se si utilizzano nomi utente come salt, questo può essere un problema se i nomi utente cambiano. Praticamente, (nonostante quanto detto nei documenti di progettazione del cliente) ho scoperto che gli utenti spesso vogliono cambiare i nomi utente.

— SilentSteel,

5

@ NateC-K, l'idea di sale per sito di cui stai parlando si chiama pepe.

— Pacerier,

35

Gli standard attualmente accettati per le password di hashing creano un nuovo salt di 16 caratteri per ogni password e memorizzano il salt con l'hash della password.

Ovviamente dovrebbe essere presa un'adeguata cura crittografica per creare sale davvero casuale.

— David Schmitt
fonte

6

Il personaggio è un po 'mal definito. Dovresti dire byte .

— CodesInCos

10

@CodesInChaos Credo che tu intenda l' ottetto ;-)

— user2864740

1

Ciao! Sembra che l'articolo di Wikipedia sia cambiato - forse dovresti fare riferimento a en.wikipedia.org/wiki/PBKDF2 o qualcosa del genere?

— Boris Treukhov,

5

O ancora meglio owasp.org/index.php/Password_Storage_Cheat_Sheet

— Boris Treukhov,

24

Modifica: la mia risposta di seguito risponde alla domanda come posta, ma la risposta "reale" è: basta usare bcrypt , scrypt o Argon2 . Se stai ponendo domande come questa, stai quasi sicuramente usando strumenti a un livello troppo basso.

Onestamente, non c'è motivo difendibile per non avere il sale della stessa lunghezza esatta della password con hash. Se stai usando SHA-256, allora hai un hash a 256 bit. Non c'è motivo di non usare un sale a 256 bit.

Più di 256 bit non ti garantiranno alcun miglioramento della sicurezza, matematicamente. Ma andare con un sale più corto può sempre finire con una situazione in cui una tavola arcobaleno raggiunge la tua lunghezza del sale - specialmente con sali più corti.

— Stephen Touset
fonte

10

Questo non è che affare grande un; l'utente noterà a malapena la differenza tra un hash di millisecondo e un hash di mezzo secondo, inoltre l'hashing della password in realtà dovrebbe richiedere più tempo per rallentare gli attacchi di forza bruta, anche se i tre colpi tipici bloccati per 15 minuti sono migliori. Stai "sprecando" i cicli della CPU per fare questo? Sì come ti pare. La CPU trascorre comunque più tempo inattivo che non sulla maggior parte dei siti Web, quindi che importanza ha? Se riscontri problemi di prestazioni, ridimensionali.

— Randolpho,

14

I sali si difendono dai tavoli arcobaleno. Un salt a 512 bit con un hash a 256 bit comporterà comunque solo 256 bit di entropia nella password finale.

— Stephen Touset,

8

L'hashing lento è una funzionalità, non un bug.

— uscita il

7

Se si dispone di un hash a 3 bit, il sale a 9999 bit continuerà a contenere solo 3 possibili bit di entropia. Una tabella arcobaleno dovrebbe trovare solo tre sali per ogni password che generano un output diverso, che è un fattore moltiplicativo costante e quindi scartato dal big-O.

— Stephen Touset,

2

.................................................. .................................... sistema particolare. Lo scopo dei sali è fermare gli attacchi precomputazione in modo che gli hash non possano essere cercati e immediatamente invertiti in testo normale . Con un salt a 9999 bit, la tua password rimane segreta , mentre con un salt a 3 bit, la tua password è ora conosciuta in tutto il mondo (e possono usarla per accedere agli altri account poiché molte persone spesso riutilizzano le password). Trovo divertente che 5 persone qui abbiano effettivamente votato il tuo commento a causa della parola "entropia" in esso.

— Pacerier,

7

Wikipedia :

I metodi SHA2-crypt e bcrypt — usati in Linux, BSD Unixes e Solaris — hanno sali di 128 bit. Questi valori di sale più grandi rendono gli attacchi di pre-calcolo per quasi ogni lunghezza di password impossibile per questi sistemi nel prossimo futuro.

128 bit (16 byte) saranno sufficienti. Puoi rappresentarlo come una sequenza di 128 / 4 = 32cifre esadecimali.

— Andrii Nemchenko
fonte

Mi sembra che un esempio di ciò che usano altri sistemi sicuri sia un ottimo esempio di ciò che è la migliore pratica.

— cjbarth,

1

@ mklement0 Grazie, ho aggiornato la risposta.

— Andrii Nemchenko,

2

Una risposta potrebbe essere quella di utilizzare come dimensione del sale il valore che l'hash che si intende utilizzare fornisce in termini di sicurezza.

Ad esempio, se si intende utilizzare SHA-512, utilizzare sale a 256 bit poiché la sicurezza fornita da SHA-512 è 256 bit.

— Roberto Martelloni
fonte