Sì e no.

Salt ti protegge da qualcuno che ottiene il tuo database e deduce le password effettive anche se sono sottoposte ad hashing. (Se qualcuno ruba il tuo 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 utilizzati, perché molte persone usano le loro password su più siti, che poi verrebbero anche compromessi.) pertanto, sia l'hashing che il salting sono una pratica standard per proteggere in modo ottimale i tuoi utenti.

Tuttavia, salt non ti protegge dalle persone che scelgono "password123" come password e un utente malintenzionato che prova semplicemente password comuni. Niente può proteggerti da questo: se l'utente può inserire la sua password scadente e ottenere l'accesso, può farlo anche un aggressore (il sistema non sa chi si trova all'altro capo della linea, che è l'intero punto delle password per cominciare ).

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

Il sale non è lì per prevenirli. I sali sono lì per prevenire gli attacchi usando le tabelle arcobaleno, che sono fondamentalmente elenchi di hash e le loro password. Questo è quando un attacco ha già l'hash della tua 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.

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

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

  PASSWORD UTENTE PASSWORD CON HASH ==================================== ==== dio hamfist de898928393a893bttltoad god de898928393a893woob god de898928393a893marco-fiset mypass1 1238ffff2342399dean password2 a44ca77446ff449  

Se qualcuno dovesse pre-calcolare in anticipo gli hash in memoria (una tabella arcobaleno) allora sarebbe banale per loro controllare se de898928393a893 esistesse nell'elenco delle password. Saprebbero quindi che è possibile accedere a tutti questi account utente 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 utilizza la stessa combinazione email / password).

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

  PASSWORD UTENTE PASSWORD SALT HASHED ================ =============================== hamfist god ae # o abf4388ff343401bttltoad god cdo @ 29292d919100001woob god! doe 3902dda99210099marco-fiset mypass1 12uo aaffff121bcce13dean password2 TEe9 b44ca7743324234  

Ora un tavolo arcobaleno non aiuta davvero. Invece di avere solo bisogno dell'hash per god , ad esempio, dovresti pre-calcolare l'hash per god + <all_potential_salts> . Un po 'limita ciò che puoi memorizzare in memoria.

Tuttavia, se qualcuno vuole ottenere specificamente hamfist , ha il sale poiché è memorizzato nel database, quindi questo non rallenterà affatto un tentativo di cracking.

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

Hai detto che i sali non sono utili, ma per quanto riguarda le tabelle arcobaleno? Perché suggeriresti alle persone di non usare i sali?

Come descrive l'articolo di Provos & Mazières, bcrypt ha i sali integrati per prevenire gli attacchi al tavolo arcobaleno. Quindi non sto dicendo che i sali sono senza scopo, sto dicendo che non impediscono il dizionario o gli attacchi di forza bruta (cosa che non fanno). [enfasi aggiunta]

Come hanno detto gli altri, ti proteggono semplicemente dalle tabelle arcobaleno e forse differenziano gli stessi hash delle password tra siti diversi. Non dovresti fare alcuno sforzo per rendere segreto il sale (molti erroneamente sostengono di metterli su un server diverso, ecc.), Mantenere il sale insieme agli hash delle password andrebbe bene. Tutti i tuoi sforzi dovrebbero essere concentrati nel rendere sicura la posizione degli hash delle password.

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

Se memorizzi il sale nel database e un utente malintenzionato ha accesso a quella tabella del database dove trova l'hash e il sale, può attaccare con forza bruta quegli hash usando il sale, quindi usando o non usare un salt è lo stesso (tranne che per il rallentamento dell'attaccante dovuto all'aumento del lavoro di hashing, che è un fattore, ma non così importante).

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