La risposta breve è che quando si parla di sicurezza, e specialmente quando si tratta di crittografia, non eseguire il rollover . Utilizzare schemi controllati che soddisfano l'approvazione della comunità di sicurezza in generale. Il tuo metodo di coltivazione in casa è praticamente garantito per avere difetti che non hai mai pensato.
Per una risposta più lunga, leggi l'eccellente trattato di Thomas Pornin su come password hash sicure . La maggior parte di ciò che scriverò qui è contenuta in quella risposta.
Per l'hashing della password, esistono tre funzioni di hashing generalmente approvate: PBKDF2 , bcrypt e scrypt . Non li confronterò in questa risposta; nessuna di queste è una scelta sbagliata. Diversi thread su Security Stack Exchange li confrontano, in particolare Qualche esperto di sicurezza consiglia bcrypt per l'archiviazione delle password? e Esistono metodi di hashing delle password più moderni di bcrypt e scrypt? .
Ora, per ottenere la risposta tecnica alla tua domanda, ci sono due cose sbagliate nell'usare ad es. SHA-256 (nome utente + password) come hash della password. La prima cosa è che i nomi utente non sono unici. Questo ha diverse implicazioni:
- In particolare, questo rende ovvio quando un utente ha scelto la stessa password su siti diversi, il che può essere di aiuto per alcuni attacchi mirati.
- L'utilizzo di un "sale" debole e prevedibile facilita anche gli attacchi non mirati che si concentrano sui nomi utente più comuni, ad es. una tabella arcobaleno con i 1000 nomi di utenti più comuni e le 1.000.000 di password più comuni ha le stesse dimensioni di una tabella arcobaleno con le 1.000.000.000 di password più comuni per gli hash non salati e cattura comunque alcune password deboli. Un sale davvero unico rende la tabella precompilata inutile.
Il sale tecnicamente non deve essere casuale, ma deve essere unico e usare una stringa casuale è il modo più semplice per soddisfare questo requisito.
Per maggiori dettagli sui sali, vedi Perché gli hash salati sono più sicuri? e Convincere il mio manager ad usare i sali . Un pepe può facoltativamente essere combinato con il salt - è una buona difesa contro alcuni attacchi comuni (dump del database con SQL injection).
Un secondo problema con il tuo approccio è che qualcosa come SHA-2 (salt + password) non è buono neanche. Una funzione di hash deve essere slow - i server legittimi calcolano solo un valore di autenticazione, mentre gli attacker devono eseguire molti tentativi falliti, quindi la lentezza penalizza maggiormente l'aggressore. Le funzioni hash di uso generale come SHA-1 e SHA-2 sono progettate per essere veloci, non sono utili per l'hashing delle password. Puoi trasformarli in una buona funzione di hash della password ripetendoli più volte, ma non eseguire il rollover, perché il diavolo si trova nei dettagli: PBKDF2 si basa su questo principio.