Ho sempre sentito dire che è meglio usare i sali sopra le password memorizzate, che poi in qualche modo vengono concatenate e cancellate in seguito. Ma non so cosa usare come sale. Quale sarebbe un buon sale?
Diciamo che hai una tabella in cui memorizzerai la password per ogni persona.
Per "salvare" la password che viene generata, fai quanto segue
hashed_password = SHA (SHA (SHA (.... SHA ("1passworda12bc34de56fg"))))))))
Archivia hashed_password, con il login e il sale, nella tabella.
login password salt
--------------------------------------
john a7b82783... a12bc34de56fg
E poi, per verificare quando un utente accede alla tua app:
hashed_password = SHA (SHA (SHA (.... SHA ("1passworda12bc34de56fg"))))))))
Verifica se hashed_password che hai calcolato è uguale a quello che è stato memorizzato nel database. Saprai se la password è corretta o meno.
Questo è tutto! Puoi ottenere il sale da qualsiasi fonte casuale che ti piace. Perché dovrebbe essere casuale? Poiché qualsiasi sale non casuale renderebbe molto più facile tentare di forzare la tua app.
La classica raccomandazione per l'hashing di salt per la password è:
/dev/random o /dev/urandom sui moderni Unix ); Ci sono molte discussioni precedenti su argomenti correlati . E, soprattutto, dovresti non implementare il tuo schema di hashing della password: dovresti utilizzare un implementazione collaudata, ben collaudata, peer reviewed (bcrypt / PBKDF2) .
La risposta è "quasi tutto", anche se alcuni sono più forti di altri.
Supponiamo che tu stia usando md5 (salt.password).
Senza sale, gli hacker creperanno rapidamente la maggior parte delle password semplicemente guardando l'hash in un tavolo arcobaleno.
Supponiamo che tu usi "x" come il sale per tutte le tue password. Molte delle tue password saranno ancora trovate, ma meno. Questo perché se la password è "p4ssw0rd", allora diventa "xp4ssw0rd" con il sale - rendendolo leggermente più difficile, ma non in modo significativo.
Ora supponiamo che tu usi "% X88Fc + 7" come il sale per tutte le tue password. A questo punto, i tavoli arcobaleno non funzioneranno. Ma, la conseguenza dell'uso di un solo sale per tutte le password, l'hacker sarà in grado di generare una tabella arcobaleno con tale assunto e di costruire tabelle arcobaleno in anticipo. È molto più sicuro, ma non perfetto.
La prossima opzione più sicura è usare il nome utente come sale, in altre parole usando 'md5 (username.password)'. Di nuovo, questo sconfigge la tabella arcobaleno standard, ma un hacker potrebbe generare una tabella arcobaleno per un nome utente specifico (come "root" o "amministratore"), in modo che ogni volta che la password viene cambiata, l'hacker può fare una ricerca in un arcobaleno tabella invece di rompere di nuovo.
Quindi, per essere ancora più sicuro, scegli un diverso sale casuale per utenti diversi. Devi memorizzare questo insieme con il nome utente e l'hash della password. Questo sconfigge completamente i tavoli arcobaleno.
Alcuni suggeriscono un generatore di numeri casuali "sicuro", piuttosto che qualcosa di semplice. Ad esempio, eseguire un MD5 (timestamp + nome utente) quando l'utente crea un account è semplice, ma non crittograficamente sicuro (dal momento che timestamp e nomi utente sono prevedibili e quindi bassa entropia). Ma dal momento che l'hacker ha comunque una copia del sale quando ruba il database, non è un problema.
Per il sale basta usare un bit a caso.
Su Linux puoi usare /dev/random . È un generatore di numeri casuali del kernel basato sul rumore ambientale. È abbastanza imprevedibile tranne che per i mechines virtuali. Quindi, se diciamo che il mouse fisico è collegato alla tua casella, quindi /dev/random ti darà bit casuali di alta qualità per il sale.
Ecco un buon articolo per iniziare. Vedi anche i riferimenti esterni.
Ecco un codice java di esempio . Guarda come il sale viene generato e memorizzato nel DB nella funzione createUser() . Tranne che per l'utilizzo di import sun.misc. ... , si tratta di un codice molto buono.
Leggi altre domande sui tag passwords password-management salt