In che modo la salatura aumenta la sicurezza? [duplicare]

Questo argomento è ampiamente documentato su tutto il web e su su questo sito , quindi dedica il tempo a fare qualche ricerca da solo sarebbe stato un modo molto più veloce per ottenere risposte. Tuttavia, se hai difficoltà a comprendere il concetto, può essere utile una semplice spiegazione.

In poche parole, modifica l'hash di una password in modo che non corrisponda fisicamente all'hash di un'altra password.

Ad esempio, un utente ha la password, "password123" e viene sottoposto a un hash SHA1. Nel database delle password, tutti gli utenti con la password "password123" avranno lo stesso hash, a causa della natura delle funzioni di hashing.

Quindi, se un utente malintenzionato dovesse violare il database e forzare brutemente la password dell'utente menzionato sopra, potrebbe cercare tutti gli hash che corrispondono a quello dell'utente originale e sapere che le sue password sono anche "password123".

Implementando un salt, gli hash delle password non sarebbero più identici tra loro, anche se la password effettiva è sempre la stessa. Ciò richiede che l'attaccante entri e tenti di forzare la seconda password (che ha un sale diverso), anche se potrebbe essere la stessa del primo. In poche parole, impedisce a un utente malintenzionato di scoprire una password e successivamente di scoprirne altre.

Nella tua domanda, hai ragione sul fatto che il sale è in genere proprio accanto all'hash, in modo tale che chiunque abbia accesso a un database di hash delle password abbia anche accesso ai sali. Tuttavia, ciò non toglie nulla allo scopo originale in quanto impedisce a più hash di essere bruto forzato in una singola ipotesi. Ogni hash deve essere indovinato da solo.

Questo argomento è stato davvero discusso a morte, quindi questa è solo la versione breve.

I sali hanno diversi vantaggi. Il più importante è che costringe un attaccante a rompere ogni hash individualmente.

Senza i sali, l'attaccante deve passare attraverso la sua lista di possibili password solo una volta. Per ogni articolo, calcola l'hash e controlla se corrisponde a uno degli hash memorizzati. Quindi per cercare uno spazio di n possibili password, l'autore dell'attacco ha bisogno al massimo di n calcoli di hash.

Con i sali, hai effettivamente cancellato ogni password con una variante unica dell'algoritmo di hash di base. Ora un utente malintenzionato non può eseguire solo un calcolo e confrontare il risultato con tutti gli hash memorizzati. Devono attaccare ogni hash individualmente. Quindi, se ci sono m hash memorizzati con sali unici, la ricerca di uno spazio di n possibili password richiede al massimo calcoli hash m * n. È più volte lo sforzo di prima.

I sali non devono essere segreti. Devono essere sufficientemente casuali in modo che siano davvero unici (non solo nella propria applicazione ma globalmente). 16 byte da una sorgente come /dev/urandom vanno bene.

Nota, tuttavia, che i sali non trasformano magicamente gli algoritmi hash deboli in quelli forti. Non proteggono un hash particolare . Inoltre, non aiutano se l'algoritmo di hash sottostante è così veloce che un utente malintenzionato può facilmente recuperare lo sforzo extra.

Quindi concetti come "salted MD5" o "salted SHA" (qualunque cosa significhi) sono privi di senso. Se l'attaccante può calcolare centinaia di miliardi di hash al secondo, semplicemente non si preoccupa di alcuni calcoli aggiuntivi. I sali sono efficaci solo nel contesto di un algoritmo di hash strong come bcrypt.