Hai bisogno di riferimenti sul motivo per cui l'accesso pubblico a un hash e un salario di password è una cattiva pratica

Ciò che è male nel rivelare la password hash-and-salt è che permette attacchi dizionario offline : poiché la password hash e the salt sono sufficienti per verificare una potenziale password, quindi, per definizione, consentono a un utente malintenzionato di provare le password sulle proprie macchine, limitate solo dal numero di PC (o altro hardware) che può radunare. Ciò contrasta con gli attacchi al dizionario online , in cui ogni tentativo deve passare attraverso il server e il tuo server non accetterà di provare miliardi di password al secondo.

L'hashing della password è una seconda linea di difesa . Non vuoi che gli aggressori ottengano informazioni sufficienti per eseguire attacchi di dizionario offline; ma quando lo fanno, almeno lo preferisci se devono pagare l'intero prezzo dell'attacco, cioè mostra solo hash delle password , non le password stesse. Inoltre, si desidera una funzione hash lenta (con milioni di iterazioni) e il sale per prevenire attacchi paralleli e altre ottimizzazioni simili (come le tabelle precompiate).

Tutto ciò riguarda la protezione delle password , come in "dati segreti che gli utenti umani ricordano". Essendo il cervello umano quello che sono, le password tendono ad essere vulnerabili agli attacchi del dizionario. Tuttavia, se riesci a convincere i tuoi utenti umani a ricordare sequenze di 20 lettere casuali (sequenze non che scelgono da sole, ma lettere generate casualmente), allora puoi mostrare i valori hash, perché le password sufficientemente casuali sono comunque fuori dalla portata degli attacchi al dizionario - probabilmente non sono più password ma chiavi . Nota che non si tratta di lunghezza ma di casualità : una password non è strong perché è lunga, ma perché è stata prodotta con abbastanza casualità in essa; hai solo bisogno di lunghezze per fare spazio alla casualità.

Se hai bisogno di un riferimento per colpire i non credenti , quindi invoca Pubblicazione speciale del NIST SP 800-118 (ancora in bozza, ma comunque pubblicata), che include in particolare questa citazione (dal" sommario esecutivo "):

Password cracking attacks can be mitigated by using strong passwords, choosing strong cryptographic algorithms and implementations for password hashing, and protecting the confidentiality of password hashes.

(L'enfasi è mia.)

L'hashing della password è un'arte difficile. Dici che usi "HMAC / SHA-1", ma HMAC non è una funzione di hash; è un algoritmo MAC . Gli algoritmi MAC utilizzano un tasto . Quello che probabilmente significa è che si utilizza una funzione di hashing della password che è stata progettata su una o più invocazioni di HMAC / SHA-1 come un blocco predefinito. PBKDF2 è una funzione di hashing della password. Include un parametro aggiuntivo che è il numero di iterazioni e questo è importante.

Vedi questa risposta per una discussione dettagliata sulla password hashing, la sua teoria e la sua pratica.

Innanzitutto, HMAC-SHA1 non è un buon algoritmo di hashing della password. Usa qualcosa come bcrypt , scrypt o PBKDF2 .

In questo caso, è assolutamente banale iniziare a decifrare le password sul tuo sistema. Le password di completamente casuali di almeno dieci caratteri possono essere ancora protette, ma qualsiasi password che sia più corta o che faccia uso pesante di pattern o parole cadrà nel giro di pochi minuti. I moderni cracker di password hanno motori estremamente sofisticati che possono prendere una parola base come "password" e cancellarne ogni permutazione plausibile ("p4 $$ wOrd!", "PaSs; WORD1234", ecc.) In una frazione di secondo. Alcuni sistemi recenti hanno persino superato la velocità di 348 miliardi di hash al secondo .

Questo è il motivo per cui il tuo attuale algoritmo non è abbastanza buono, e perché è una vulnerabilità assolutamente critica che gli aggressori possono rivelare i tuoi sali e gli hash. Gli algoritmi hash specifici delle password (in genere noti come "slow hashes") aiutano a sconfiggere questo tipo di cracker con password accelerate da GPU richiedendo grandi quantità di lavoro per calcolare una singola password. PBKDF2, ad esempio, è uno schema che utilizza un HMAC ripetuto. Effettuando 100.000 o più iterazioni, si rallentano queste macchine di cracking delle password con lo stesso fattore. Ora puoi impiegare mezzo secondo per verificare la password di un utente in casi legittimi, ma gli hacker ora richiedono giorni solo per elencare anche le password più comuni.

Gli algoritmi come scrypt vanno ancora più lontano, richiedendo una quantità configurabile di memoria per generare l'hash. Se le tue password richiedono 128 MB di memoria da calcolare, questo sarà a malapena visibile da una webapp standard. Ma per un password cracker, richiederebbe grandi quantità di memoria per calcolare gli hash in parallelo (il che è il modo in cui la maggior parte di essi raggiunge velocità così elevate).

Nella tua situazione attuale, devi chiudere la vulnerabilità che consente alle persone di rivelare sali e hash. Le password esistenti dovrebbero essere considerate compromesse a meno che non possano essere provate in modo inequivocabile. Dovresti eseguire la migrazione delle tue password a uno degli algoritmi di hashing consigliati non appena possibile. Puoi semplicemente comporre gli hash esistenti con il nuovo algoritmo, così dato h = HMAC-SHA1(password, salt) , calcolare h' = bcrypt(h) e usare h' come autenticatore.

Se tutte le password sono lunghe e veramente casuali, allora non è male. Fintanto che tutti gli hash che possono perdere non sono vulnerabili ad essere attaccati in base alle prestazioni di hashing correnti, non ci sono problemi. Detto questo, non puoi garantire che gli utenti non facciano cose stupide (e praticamente puoi garantire che lo faranno.)

In generale, gli attacchi offline contro gli hash sono molto veloci, quindi la complessità richiesta diventa molto alta, molto rapidamente. Se l'unica opzione è gli attacchi online, è possibile applicare la limitazione della velocità che aiuta a prevenire gli attacchi contro l'accesso e aumenta notevolmente la sicurezza, tuttavia è comunque valido per gli hash resistere in caso di perdita.

Non conosco documenti di settore, ma la semplice risposta è che le persone che utilizzano le cose creativamente stupide come la loro password è la ragione per cui è cattiva. P @ ssw0rdPa $ sw @ rdpAs $ wOrd non è sicuro, anche se è lungo.