Al sale, o non al sale? [duplicare]

I sali non aiutano a impedire a qualcuno di violare una password particolare. Aiutano a impedire a qualcuno di violare molte password contemporaneamente usando una tabella arcobaleno.

Supponiamo che tu abbia i seguenti utenti sul tuo sito (la password non verrebbe effettivamente archiviata nel database, solo la versione con hash).

USER         PASSWORD    HASHED PASSWORD   
========================================  
hamfist      god         de898928393a893
bttltoad     god         de898928393a893
woob         god         de898928393a893
marco-fiset  mypass1     1238ffff2342399
dean         password2   a44ca77446ff449

Se qualcuno dovesse precalcolare in anticipo gli hash per un sacco di password e archiviarle in memoria (una tabella arcobaleno), sarebbe banale per loro verificare se de898928393a893 esistesse nell'elenco delle password. Saprebbero quindi che è possibile accedere a tutti questi account utenti con la password, god . In brevissimo tempo, avrebbero accesso agli account di tutti con una semplice password che esiste nella loro tabella arcobaleno (e in qualsiasi altra parte del web quella persona usa la stessa combinazione di email / password).

Ora se aggiungi un salt casuale, tutti con la stessa password finiranno con diversi hash:

USER         PASSWORD    SALT   HASHED PASSWORD   
===============================================  
hamfist      god         ae#o   abf4388ff343401
bttltoad     god         cdo@   29292d919100001
woob         god         !doe   3902dda99210099
marco-fiset  mypass1     12uo   aaffff121bcce13
dean         password2   TEe9   b44ca7743324234

Ora un tavolo arcobaleno non aiuta davvero. Ad esempio, anziché richiedere l'hash per god , è necessario calcolare l'hash per god + <all_potential_salts> . Tipo di limiti che è possibile memorizzare in memoria.

Tuttavia, se qualcuno è fuori per ottenere hamfist in modo specifico, hanno il sale dal momento che è memorizzato nel database, quindi questo non rallenterà affatto un tentativo di cracking.

Sì e no.

Il sale ti protegge da chi ottiene il tuo database e deduce le password effettive anche se sono sottoposte a hash. (Se qualcuno ruba l'intero database, è probabile che abbia anche ottenuto i dati utente che le password avrebbero dovuto proteggere in primo luogo, ma supponiamo che le password siano ancora più preziose dei dati di utilizzo, perché molte persone usano le loro password su più siti, che potrebbero anche essere compromessi.) Pertanto, sia l'hashing che il salting sono una pratica standard per proteggere in modo ottimale i propri utenti.

Tuttavia, sale non ti protegge dalle persone che scelgono "password123" come password, e un utente malintenzionato semplicemente provando password comuni. Niente può proteggerti da questo: se l'utente può inserire la sua password zoppo e ottenere l'accesso, così può un utente malintenzionato (il sistema non sa chi è all'altro capo della linea, che è l'intero punto di password che inizia con ).

Per motivi di sicurezza, sia il fornitore che l'utente devono agire in modo minimamente competente: uno dei due non è sufficiente.

Il sale non è lì per prevenire quelli. I sali sono lì per prevenire gli attacchi usando le tabelle arcobaleno, che sono fondamentalmente liste di hash e le loro password. Questo è quando un attacco ha già l'hash della password.

Oltre alle tabelle arcobaleno, i sali impediscono a qualcuno con accesso al tuo database di sapere se una determinata coppia di utenti condivide la stessa password.

C'è un'altra sezione dell'articolo che risponde alla tua domanda:

You said salts aren’t helpful, but what about rainbow tables? Why would you suggest people not use salts?

     

Come il Provos & La carta di Mazières descrive, bcrypt ha incorporato i sali per prevenire gli attacchi della tabella arcobaleno. Quindi non sto dicendo che i sali siano senza scopo, sto dicendo che non impediscono attacchi di dizionario o forza bruta (cosa che non fanno). [emphasis added]

Come hanno detto gli altri, ti proteggono semplicemente dalle tabelle arcobaleno e forse differenziando gli stessi hash delle password tra siti diversi. Non dovresti fare alcuno sforzo per rendere il sale segreto (molti erroneamente sostengono di metterli su un altro seerver ecc.), Tenere il sale al posto degli hash delle password andrebbe bene. Tutti i tuoi sforzi dovrebbero concentrarsi sul rendere sicura la posizione degli hash delle password.

Se ho capito bene, la citazione dice "Non influenza la velocità con cui un utente malintenzionato può provare una password candidata, dato l'hash e il sale del tuo database", e "sale dal tuo database" è la parte principale qui .

Se si memorizza il sale sul database e un utente malintenzionato ha accesso a quella tabella di database in cui trova l'hash e il sale, può attaccare con forza bruta quegli hash che usano il sale, quindi usare o meno un sale è lo stesso (ad eccezione del rallentamento dell'attaccante dovuto a un aumento del lavoro di hashing, che è un fattore, ma non così importante).

Visto in questo modo, ha senso, se l'attaccante ha "sali dal tuo database".