Perché dovremmo proteggere l'accesso agli hash delle password? E a quali condizioni può essere omessa questa precauzione?
Gli algoritmi di memorizzazione delle password sicure hanno due caratteristiche principali: sono a senso unico e sono lenti.
Ma cosa succede se la tua password è nella top 10 delle peggiori password, come "admin" o "123456"? Quindi un aggressore sta per indovinare che entro pochi tentativi, indipendentemente da quanto strong sia l'algoritmo di hashing.
Pertanto, le persone con password deboli saranno sempre a rischio se il loro hash è noto a un utente malintenzionato. Ecco perché le teniamo segrete.
Quando accediamo ad un sistema, non vogliamo aspettare 5 minuti perché il server completi l'algoritmo della password, quindi quegli algoritmi sono ancora piuttosto veloci (qualcosa come 0,1 secondi). Poiché i computer diventano più veloci nel tempo, è anche necessario aumentare il numero di calcoli eseguiti, in modo da impiegare ancora un attaccante (con hardware moderno) per molto tempo. O forse vogliamo passare ad un diverso algoritmo che protegge da un certo tipo di programma di cracking ASIC o GPU. In questi casi, se il vecchio hash è noto a un utente malintenzionato, può craccare la password dell'utente più facilmente. Quindi inoltre, mantenendo gli hash segreti il più a lungo possibile, abbiamo anche la protezione più aggiornata nel momento in cui gli hash vengono violati.
Alcune persone includono pepe negli hash delle password (vedi questa domanda o Wikipedia ), nel qual caso sarebbe perfettamente sicuro pubblicare la password hash fino a quando il valore del pepe rimane un segreto . Ma poi la domanda è: perché dovresti? Di solito non c'è alcun vantaggio nel pubblicare gli hash. Quando il valore del pepe perde, gli attaccanti possono iniziare a scoppiare gli hash più vecchi mai pubblicati. Se proteggi gli hash invece di pubblicarli pubblicamente, gli hacker devono prima ottenere sia il pepe che il database degli utenti prima che possano iniziare a scoppiare qualcosa.
Omettere questa precauzione (di proteggere gli hash delle password) non dovrebbe mai essere fatto senza che l'utente sia avvisato del rischio. Un esempio di questo è un tripcode , dove l'hash viene pubblicato come prova di identità senza bisogno di un database. Questo è l'unico caso in cui posso pensare a dove pubblicare gli hash dei segreti memorizzati è una buona idea. Altri hash, come le firme del software, sono ovviamente un argomento diverso perché quelli non funzionano come password.
Nel corso degli anni gli algoritmi di hashing delle password raccomandati sono stati modificati più volte come vulnerabilità e si sono verificati progressi tecnologici imprevisti. Non c'è garanzia al 100% che un hash che è sicuro oggi sarà ancora sicuro tra 10 anni.
Proteggendo gli hash dall'accesso da parte di un utente malintenzionato si riduce il rischio di compromissione nel caso in cui venga catturato un hash, e in futuro è scomposto.
Questo è anche un motivo per cui più organizzazioni richiedono che le password vengano cambiate regolarmente.
Ci sono stati molti attacchi di grandi dimensioni in cui i database delle password vengono scaricati e alla fine craccati. Rockyou è uno dei più notevoli, la sua lista di parole è ora inclusa in tutte le istanze di Kali. I crimini semplicemente rallentano un attaccante. Mentre alcune persone guardano alla matematica e dicono "oh, è totalmente sicuro, ci vorrebbero X milioni di anni per risolvere il problema", che non è sempre realistico quando vediamo continuamente nuove vulnerabilità e cambiamenti nei paradigmi informatici.
Sono d'accordo su tutte le risposte scritte prima di me, ma vorrei rispondere brevemente a questa domanda:
Dobbiamo proteggere gli hash perché questo è ciò che tutti gli hacker oi pentesters vogliono ottenere per rompere gli hash e trovare le password attraverso brute-force, attacchi dizionario e tabelle arcobaleno. Se riesci ad accedervi facilmente con gli hash delle password, li renderai molto felici, di sicuro.
Se proteggi gli hash, proteggi le tue deboli password.
Aggiunto alle risposte di cui sopra, alcuni protocolli deboli sono vulnerabili all'attacco "Passa l'hash", in cui tutto l'utente malintenzionato deve accedere è il nome utente e l'hash della password. L'attaccante non ha bisogno di forzare l'hash. Quindi meglio non rischiare di pubblicare hash.