Perché crittografiamo le password? È per proteggere la password da intercettazioni? proteggere la password dopo averla salvata nel database? tutti e due? o per qualche altro motivo?
Ho scritto un articolo del blog specificamente su questo argomento. Riepilogo: la password deve essere sottoposta a hash ("crittografato" non è il termine corretto per tale scopo) per proteggere dagli aggressori che ottengono l'accesso di sola lettura al database in cui un server memorizza tutto ciò di cui ha bisogno per verificare le password.
La crittografia di una password viene in genere utilizzata per proteggerla da intercettazioni. Ad esempio, quando si accede a un sito Web che è stato configurato correttamente, la password viene crittografata grazie a SSL. Nessun intercettatore può strappare la password in transito.
Come per salvare una password crittografata in un database, a meno che non ci sia un buon motivo per farlo e sai cosa stai facendo, questa è una cattiva idea. Memorizzare un digest (ad esempio, sha-256 (salt + password)) è un'idea molto migliore. La ragione di ciò è la posizione in cui è memorizzata la chiave di crittografia? Sul server. Quindi, se un hacker può penetrare nella macchina e rubare il database, sicuramente può rubare la chiave di crittografia e decifrare facilmente ogni password.
Un esempio valido mi viene in mente, tuttavia, per memorizzare una password crittografata in un database è un gestore di password.
Il modo giusto non è quello di memorizzare le password (anche crittografate), ma piuttosto memorizzare un hash salato della password.
A volte è necessario memorizzare una password, in genere per accedere / accedere ad altri sistemi. Quindi devi archiviarlo crittografato in modo che se qualcuno lo ottiene (tramite SQL injection o qualsiasi altra cosa) non sarà in grado di usarlo per accedere a quei sistemi.
Usa l'hashing, invece di crittografare le password. Perché? Bene, per crittografare qualcosa, hai bisogno di un'altra chiave (un'altra password). Quindi, come conserveresti quella chiave in modo sicuro? Saresti intrappolato in un ciclo.
Quindi, usa una funzione di hashing. Guardando su Internet, trovi milioni di articoli e suggerimenti che affermano di utilizzare funzioni come MD5, SHA1, SHA256, HMAC, Hash salati, ... e così via. L'elenco è lungo, ma non usarli.
Utilizza PBKDF2 con un sale a 64 bit per utente (probabilmente derivato da un generatore di numeri pseudocascrittografici ). Uno dei motivi per utilizzare PBKDF2 su qualsiasi altra funzione di hashing è che è lento, il che significa che non è molto vulnerabile agli attacchi di forza bruta. Un sale per utente aiuta a proteggersi dagli attacchi tabella arcobaleno .
Quindi memorizzeresti
USERNAME, PBKDF2DIGEST, SALT
come record nella tabella SQL e sei a posto!
(preferisco PBKDF2 su bcrypt poiché sembra più usato e quindi più testato)
L'hash viene utilizzato per proteggere le password all'interno del database (in un sistema operativo come Linux o un'app). Per proteggere l'hash da attacchi come le tabelle arcobaleno, viene aggiunto all'hash un valore di sale. Il sale renderà gli attacchi delle tavole arcobaleno poco pratici perché il valore del sale è unico per ogni utente.
La protezione della password da intercettazioni di solito utilizza la crittografia. Ad esempio, invia la password su SSL.
Segui la risposta di Thomas Pornin sopra. Sapere che è necessario hash + salare le password prima di memorizzarle non è sufficiente. Sono sufficienti informazioni per metterti nei guai.
Ad esempio, un round di hashing md5 è tremendamente debole, con un'impostazione di 8 GPU e 33,1 miliardi di hash al secondo , puoi rompere tutte le password a 8 cifre costituite da caratteri alfanumerici in 15 ore.
Thomas parla di bcrypt e PBKDF2 e dello sfondo del loro utilizzo.
Leggi altre domande sui tag encryption passwords password-management