I sali sono inutili per sicurezza se l'attaccante li conosce?

Question

Diciamo che ho una tabella di utenti definiti in questo modo:

CREATE TABLE `users` (
    `id` INTEGER PRIMARY KEY, 
    `name` TEXT, 
    `hashed_password` TEXT, 
    `salt` TEXT 
) 

Quando viene creato un utente, un sale generata a caso è prodotto e memorizzato nel database insieme ai risultati di qualcosa come get_hash(salt + plaintext_password).

Mi chiedo se un utente malintenzionato possa mettere le mani su questi dati, sarebbe in grado di utilizzarlo per decifrare le password degli utenti? In tal caso, qual è il modo in cui potrebbe essere prevenuto?

Answer 1

No, non sono inutili.

Fintanto che si utilizza un sale unico per ogni riga, il sale sarà impedire rallentare un attacco. L'attaccante dovrà montare un attacco di forza bruta, invece di usare rainbow tables contro gli hash delle password.

Come menzionato nei commenti, è necessario assicurarsi che il sale sia una misura ragionevole.

Answer 2

Se un utente malintenzionato conosce il sale, la password hash e l'algoritmo di hash, può quindi montare un attacco di dizionario a forza bruta (o attacco arcobaleno).

Answer 3

Conoscere il sale consente di eseguire un attacco di forza bruta, ma ciò non lo rende inutile. Salt impedisce all'utente malintenzionato di utilizzare una tabella arcobaleno già generata (che è possibile trovare sul Web).

Il modo migliore per impedire la forzatura brute è semplicemente l'uso di password lunghe e complesse.

Answer 4

Salting è stato introdotto (o almeno reso popolare) nel file UNIX/etc/passwd, che era leggibile a livello mondiale. Di solito si presume che il sale e la password crittografata siano noti al cracker. Lo scopo del sale è il rallentamento del processo di cracking (poiché la stessa password non verrà mappata sulla stessa stringa crittografata); è non un segreto in sé.

Answer 5

No, non è inutile.

Per attaccare con successo un account, un utente malintenzionato deve conoscere il sale per l'account (e il sale di ogni account dovrebbe essere diverso), l'algorightm hashing utilizzato, e la finale hash password memorizzata.

Dato tutto di tali informazioni, è possibile scrivere un programma che continua a cercare di hash password diverse potenziali finché non trova quello che corrisponde.

Se si tratta di un cattiva sale (troppo semplice o corto), questo può essere reso molto più veloce perché il programma può utilizzare le tabelle arcobaleno di ricerca in modo che corrisponda l'hash della password memorizzata finale alla stringa che è stato hash, e poi basta sottrarre il sale. Ma hanno ancora bisogno di tutte le informazioni.

Se si tratta di un sale condiviso, questo è un male perché un attaccante e utilizzare il sale per generare un tavolo arcobaleno in anticipo che va bene per qualsiasi account sul vostro sistema.

Answer 6

Questo dovrebbe darvi un'idea di come funziona.

Diciamo che si desidera crittografare una parola "segreto". Dopo che è stato crittografato, digli che ora assomiglia a questo 00110010.

Se un hacker conosce l'algoritmo di crittografia, è possibile creare una tabella di parole e i relativi valori crittografati corrispondenti. Quindi prendono la password crittografata "00110010" e la trovano nella tabella. Ora sanno che la password utilizzata per generare "00110010" era la parola "segreto". Se salvi prima la parola, allora una tabella di ricerca generica sarà inutile per l'hacker. (Una tabella di ricerca generica è una tabella di parole di dizionario non salate e i loro valori crittografati)

Se salti la parola prima ("saltsecret"), ora il valore crittografato sarà diverso e l'hacker non lo troverà nella ricerca tavolo.

Tuttavia, possono ancora iniziare a creare la propria tabella di ricerca da zero utilizzando il proprio sale e alla fine saranno in grado di invertire le password di ricerca.

Quindi, per rispondere alla domanda, se le password sono sufficientemente complesse, occorreranno secoli affinchè l'hacker le capisca. Puoi cambiare il tuo sale ogni anno e dovrebbero iniziare a creare un tavolo tutto da capo.

Answer 7

Assumendo attacco di forza bruta degli algoritmi MD5, SHA1, SHA256 con GPU ha un throughput superiore a 1 miliardo di tentativi al secondo e SHA512 circa 300M/s. Se si utilizza uno di questi algoritmi, si rallenterà l'hacker che ha usato la tabella arcobaleno (meno probabile), ma non rallenterà l'hacker che ha usato l'attacco di forza bruta (più probabilmente). In definitiva non ti proteggerà, aggiunge solo un po 'di sicurezza contro la tabella arcobaleno obsoleto (per questi algo). Un po 'è meglio di niente.

Ma se si utilizza un algoritmo più forte (ad esempio bcrypt), il sale vale sicuramente la pena anche se memorizzato con hash perché la forza brut non è fattibile in termini di tempo, quindi l'arcobaleno ha senso.

Date un'occhiata a questo article e per riassumere:

Se sei un utente:

Assicurarsi che tutte le password sono 12 caratteri o più, idealmente molto di più. Raccomando l'adozione di frasi "pass", che non sono solo molto più facili da ricordare delle password (se non del tipo), ma sono anche incredibilmente sicure contro le forzature brute semplicemente a causa della loro lunghezza.

Se sei uno sviluppatore:

Usa bcrypt o PBKDF2 esclusivamente per hash tutto il necessario per essere sicuro. Questi nuovi hash sono stati specificamente progettati per essere difficili da implementare su GPU. Non usare altre forme di hash. Quasi tutti gli altri programmi di hashing popolari sono vulnerabili al bruto forcing tramite array di GPU commodity, che diventano più veloci e più paralleli e più facili da programmare per ogni anno.

Scritto da Jeff Atwood