Come memorizzare le password * correttamente *?

Question

Un article che mi sono imbattuto qui a SO forniti i collegamenti per other articles che a sua volta fornito i link a evenmorearticles ecc

E alla fine mi è stato lasciato completamente perplesso - quindi qual è il modo migliore per conservare password nel DB? Da quello che posso mettere insieme dovresti:

• Utilizzare un lungo (almeno 128 bit completamente random), che viene memorizzato in testo normale accanto alla password;
• Utilizzare diverse iterazioni di SHA-256 (o anche maggiore livello SHA) sulla password salata.

Ma ... più leggo sulla crittografia e più mi rendo conto che non capisco davvero nulla, e che le cose che avevo pensato per essere vero per gli anni sono in realtà sono flat out sbagliato. Ci sono esperti in materia qui?

Aggiunto: Sembra che ad alcune persone manchi il punto. Ripeto l'ultimo link sopra riportato. Questo dovrebbe chiarire le mie preoccupazioni.

https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2007/july/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/

Answer 1

Hai capito bene. Solo due suggerimenti:

1. Se un giorno SHA1 diventa troppo debole e si desidera utilizzare qualcosa di diverso, è impossibile unhash le vecchie password e rimaneggiamento con il nuovo regime. Per questo motivo, suggerisco di allegare ad ogni password un numero di "versione" che ti indichi quale schema hai usato (lunghezza del sale, quale hash, quante volte). Se un giorno hai bisogno di passare da SHA a qualcosa di più forte, puoi creare password di nuovo stile mentre hai ancora password vecchie nel database e distinguerle ancora. Migrare gli utenti al nuovo schema sarà più facile.

2. Le password passano ancora da utente a sistema senza crittografia. Guarda su SRP se questo è un problema. SRP è così nuovo che dovresti essere un po 'paranoico nell'implementarlo, ma finora sembra promettente.

Edit: Risulta bcrypt mi ​​ha battuto ad esso sul numero 1. L'idea informazioni memorizzate è (costo, sale, hash), dove il costo è quante volte la hashing è stato fatto. Sembra che bcrypt abbia fatto qualcosa di giusto. Aumentare il numero di volte che l'hash può essere fatto senza l'intervento dell'utente.

Answer 2

penso che non c'è iterazione extra sulla password necessaria, juste assicurarsi che non v'è un sale, e un Complexe uno;) Io personnaly uso SHA-1 combinato con 2 frasi chiave di sale.

Answer 3

In verità dipende da cosa sono le password. Si dovrebbe prendere cura di memorizzare qualsiasi password con cura, ma a volte è necessaria molta più cura di altri. Come regola generale, tutte le password dovrebbero essere sottoposte a hash e ogni password dovrebbe avere un valore univoco.

In realtà, i sali non devono essere così complessi, anche quelli piccoli possono causare un vero incubo per i cracker che cercano di entrare nel sistema. Vengono aggiunti a una password per impedire l'utilizzo delle tabelle Rainbow per hackerare le password di più account. Non aggiungerei una singola lettera dell'alfabeto a una password e chiamarla salata, ma non è necessario renderla una guida univoca che viene crittografata da qualche altra parte nel database.

Un'altra cosa riguardante i sali. La chiave per creare una password + sale funziona quando l'hashing è la complessità della combinazione dei due. Se si dispone di una password di 12 caratteri e si aggiunge un 1 carattere saltato, il sale non fa molto, ma crackare la password è ancora un'impresa monumentale. È vero anche il contrario.

Answer 4

La lunghezza del sale non ha importanza, purché sia ​​univoca per un utente. Il motivo per un salt è che un determinato tentativo generato con una corrispondenza hash è utile solo per una singola riga della tabella utenti nel DB.

Answer 5

Detto semplicemente, utilizzare un algoritmo di hash crittograficamente sicuro e un po 'di sale per le password, che dovrebbe essere sufficiente per il 99,99% di tutti i casi di utilizzo. Il collegamento debole sarà il codice che controlla la password e l'immissione della password.

Answer 6

Uso:

1. archiviazione password con hash
2. Un sale al livello di utente 128+ bit, casuale, rigenerata (cioèsi fanno nuovi sali quando si creano nuovi hash delle password, non si mantiene costantemente lo stesso sale per un dato utente)
3. Un metodo di hashing forte e computazionalmente costoso
4. Metodologia leggermente diversa (algoritmo hash, quanti hashing iterazioni che si utilizzano, quale ordine i sali sono concatenati in, qualcosa) da entrambe le eventuali 'guide di implementazione standard' come questi e da qualsiasi altra applicazione di memorizzazione delle password che hai scritto