Perché l'hashing della password è considerato così importante?

L'esperienza ha insegnato alla comunità che è effettivamente impossibile tenere fuori gli intrusi. Si tratta di quando, non se, qualcuno avrà accesso ad un database delle password.

Non importa che tu sia un blog a caso o un dipartimento governativo da diversi miliardi di dollari, devi presumere che qualcuno un giorno possa accedervi. E molto spesso, avranno abbastanza accesso per leggere il database ma non abbastanza accesso per, per esempio, inserire un man-in-the-middle che raccoglie le password in chiaro mentre sono utilizzate per autenticare qualcuno.

Ad esempio, potrebbero non hackerare il tuo server primario, potrebbero solo hackerare un server che contiene copie di backup del tuo database.

Inoltre, la maggior parte delle organizzazioni ha molti dipendenti. Un dipendente non ha bisogno di hackerare la rete per visualizzare il database, potrebbe avere già un accesso illimitato (specialmente se sono un ingegnere o un amministratore di sistema). Ci sono molte ragioni per cui è una cattiva idea per i tuoi dipendenti conoscere le password dei clienti.

Anche se il tuo sito web è completamente inutile e non sarebbe importante se qualcuno vi si intromettesse. Il nome utente e la password utilizzati per accedere al tuo sito web sono spesso identici a quelli usati per accedere ad altri servizi molto più importanti.

Ad esempio, qualcuno potrebbe scrivere un bot che tenta di accedere al negozio iTunes di Apple con ogni nome utente / password nel database e, se ha successo, inizia ad acquistare cose attraverso il negozio. Questo attacco potrebbe avere successo per ben il 10% degli utenti nel tuo database e molti di questi utenti non noteranno nemmeno che sono stati fatturati $ 4,99. Questo non è un attacco teorico, accade tutto il giorno ogni giorno e tenta di fermarlo non sempre riesce.

EDIT: E nei commenti, @emory ha fatto un altro punto che ho dimenticato: qualcuno potrebbe archiviare un mandato di comparizione o usare qualche altro procedimento legale per ottenere l'accesso al database, consentendo loro di vedere password in chiaro a meno che non si disponga di un buon hash. Nota che non solo le forze dell'ordine possono farlo, qualsiasi avvocato privato con un solido procedimento legale nei tuoi confronti può ottenere l'accesso al tuo database.

If so, then why is such an emphasis put on building secure password databases, instead of secure systems that would prevent unauthorized access to important user information?

Perché questa è una cosa difficile da fare veramente . Non c'è modo di garantire che il tuo sistema sia al 100% a prova di hack. In effetti, se fai un reclamo su Reddit, il tuo sito sarà probabilmente compromesso entro un'ora.

Esiste un termine comunemente usato in sicurezza chiamato Difesa a livello approfondito . Un database delle password compromesso non riguarda solo la tua applicazione. La maggior parte delle persone utilizzerà la stessa combinazione di nome utente e password per più siti Web. Ciò rende banale per un utente malintenzionato che ha compromesso un singolo database di password per accedere a più servizi che un utente utilizza. Questo è il motivo per cui spesso visualizzi raccomandazioni di siti Web che sono stati compromessi per consentire all'utente di modificare le proprie password su tutti i loro account.

Anche se consideri importante l'applicazione tua , ci sono molte cose che un utente malintenzionato può fare se ha le password in chiaro dei tuoi utenti. È difficile per un utente malintenzionato modificare direttamente i valori del database senza rilevamento. Tuttavia, con una password in testo in chiaro compromessa, può semplicemente accedere a un account utente e apportare le modifiche. Questo è molto difficile da rilevare.

Oltre ai motivi già indicati ce n'è un altro:

Una password dovrebbe essere privata!

Avere un testo in chiaro significa che tu o qualcuno dei tuoi colleghi di gestione o di sviluppo hai accesso a tutte le password e potresti impersonare qualsiasi utente. Ora probabilmente stai pensando: non lo faremo mai, è sbagliato!

Pensa a un sistema bancario: gli amministratori del database avrebbero tutti accesso alle password. Ciò significa che possono semplicemente accedere al tuo account da qualsiasi luogo e prelevare denaro. Metteresti i tuoi soldi in una banca del genere sapendo questo? Ancora peggio ... molte persone usano la stessa password in più posizioni. Ora potevano accedere al conto bancario e, con informazioni sufficienti in molti altri luoghi.

Ricorda che molti attacchi sono all'interno di lavori - persone con informazioni privilegiate. Gli aggressori non vengono tutti da fuori.

Ci sono molti modi in cui un database con password può finire in mani indesiderate. Se le password non vengono cancellate in modo sicuro quando ciò accade, il proprietario del sito Web è responsabile e in grossi problemi, perché spesso gli utenti riutilizzano le loro password anche su altri siti. Vorrei darti alcuni esempi di come un database può perdere:

• SQL injection è un attacco facile contro il tuo sito web. Ho fatto una piccola demo per mostrare quanto sia facile. Basta fare clic sulla freccia successiva per ottenere input dannosi. L'iniezione SQL può essere gestita scrivendo codice pulito, ma spesso si utilizzano librerie di terze parti o non si è sviluppato il codice sorgente da solo, nel qual caso il codice non sicuro potrebbe essere sfuggito.
• Se stai ospitando il tuo sito web con un provider esterno, almeno lo staff della società di hosting ha libero accesso al database. Spesso anche altre persone hanno accesso: forse hai bisogno di uno sviluppatore per risolvere un determinato problema o per estendere la tua pagina.
• Anche i backup sono un problema. Se i backup non vengono archiviati con la stessa cura con cui il server in esecuzione è protetto, o se vengono gettati via senza cancellarli correttamente, le password perdono.
• Se un server viene scartato, deve essere pulito prima di eliminarlo. Nel caso dell'hosting esterno, questo non è sotto il tuo controllo. La pulizia può essere piuttosto difficile sui sistemi RAID.
• Sempre più dati vengono archiviati nei servizi cloud. Una cosa utile, queste nuvole, ma è anche nuvoloso dove finisce il tuo database, e la corretta pulizia in un cloud potrebbe anche essere impossibile.

Un principio di sicurezza è che non esiste un singolo meccanismo a prova di proiettile, ma piuttosto si dovrebbe fare affidamento su più meccanismi per proteggere il sistema / dati. In altre parole, difesa in profondità. Quindi, piuttosto decidere tra (a) proteggere il database delle password o (b) proteggere il sistema in cui risiede o viene utilizzato, dovresti fare entrambe le cose.

Questo post di blog tratta questa domanda. Il riassunto è che hai bisogno di un hashing della password come seconda linea di difesa, quando gli aggressori realizzano una interruzione parziale, di sola lettura . Questa è una conseguenza frequente degli attacchi SQL injection, ma si verifica anche quando un nastro di backup viene rubato o quando un vecchio disco viene scartato. In particolare, quando un disco si guasta, l'errore può essere quello della scheda elettronica, ma il supporto magnetico contiene ancora tutti i dati. Se il disco non si avvia, il sysadmin non sarà in grado di cancellare (facilmente) il contenuto. Ma se il disco viene semplicemente gettato in un cassonetto, un attaccante industrioso può recuperarlo, sostituire la scheda elettronica e leggere tutti i dati.

Anche se è meglio non permettere agli attaccanti di dare un'occhiata alle viscere del tuo server, in pratica, tali violazioni si verificano in pratica, e faresti meglio a proteggerti. Vedi anche questa risposta dettagliata per come dovrebbe essere fatto l'hashing della password ; l'idea di base è che per verificare la password di un utente, il server DEVE contenere alcuni dati dipendenti dalla password, e un dump completo del contenuto del server è quindi sufficiente per "provare le password a casa". Pertanto, l'hashing della password è il migliore che si possa fare (in teoria), a meno che l'hardware resistente alla manomissione non sia incluso nell'immagine.

msn sopra menzionato la necessità di privacy in-house; Aggiungerei un altro motivo basato su questo: non puoi fidarti completamente di tutti coloro che hanno accesso fisico al tuo database. Hashing protegge il database dal compromesso interno e dai compromessi esterni.

Uno dei punti che non penso è menzionato nelle risposte qui. Penso che la ragione principale per l'implementazione dell'hash delle password non sia quella di aggiungere un ulteriore livello per gli attacchi dall'esterno, ma semplicemente renderli illeggibili a quelli all'interno della rete.
Un sacco di attacchi provengono dalla tua rete di fiducia. Uno sviluppatore incazzato o un amministratore di sistema non dovrebbe essere in grado di leggere le password unhashed dell'utente, anche se ha accesso al database.