L'unico computer veramente sicuro è quello isolato da Internet, spento, scollegato, sepolto in un bunker a 100 piedi sotto terra, con guardie armate all'unico ingresso. Anche in questo caso, lo controllavo di tanto in tanto.
L'hash delle password fa parte di ciò che è noto come "sicurezza in profondità". Hai ragione sul fatto che, in un mondo ideale, non commetteresti errori che darebbero agli aggressori l'accesso a quei dati, quindi in teoria non avrebbe importanza se fossero password o hash in chiaro. In un mondo reale, le intrusioni si verificano ed è notevolmente difficile prevedere come e dove si verificheranno. L'idea alla base della sicurezza in profondità è di fare in modo che, in teoria, anche se un utente malintenzionato compromette il tuo sistema in qualche modo, ti sei adoperato per mitigare il danno.
Nel mondo reale, c'è una necessità naturale di accedere agli hash su base regolare. Ogni volta che un utente effettua il login, è necessaria la possibilità di accedervi. Di conseguenza, sono quasi sempre accessibili a qualunque applicazione stia effettuando l'autenticazione. Se qualcuno compromette la tua applicazione, potrebbe essere in grado di leggere dati che non avrebbe dovuto essere in grado di leggere.
I modi in cui si verificano questi attacchi sono infiniti. Puoi avere attacchi SQL injection se non sei riuscito a disinfettare i tuoi input. Potresti avere un buffer overrun, dando all'aggressore la possibilità di eseguire il proprio codice. Potresti avere un errore di autorizzazione, rendendo accidentalmente un file leggibile dalle persone quando non dovresti. L'aggressore potrebbe mettere le mani su uno dei tuoi nastri di backup a causa di una cattiva gestione da parte del tuo servizio di backup!
Tutti questi attacchi danno a un utente malintenzionato un punto d'appoggio sul tuo computer, ma non sempre si traducono in un'interruzione completa. Potresti aver effettuato il chroot del tuo server SQL, in modo che il processo del server SQL non possa letteralmente vedere l'intero resto del computer. Tuttavia, in tali situazioni, le informazioni di accesso necessarie agli utenti devono essere alla portata del server SQL o non hanno alcun valore. Pertanto, le informazioni di accesso vengono tipicamente compromesse prima che si verifichino altre compromissioni più nefaste.
Hashing delle password, diminuisce il loro valore. Un hash non è utile ai fini del login. Devono avere la password con hash a quel valore. Possono o non possono essere in grado di permettersi il costo di rompere l'hash. Nel migliore dei mondi, non hai mai dovuto preoccuparti di questo in primo luogo, ma se ti iscrivi all'approccio security in profondità, ti assicuri che anche un'intrusione riuscita non comprometta tutti i tuoi dati.