Qual è il vero vantaggio dell'utilizzo di un algoritmo "più sicuro" come bcrypt per l'hashing delle password?

Ottenere accesso in sola lettura è uno scenario molto più probabile dell'accesso in scrittura: dopo tutto, l'accesso in lettura a un vecchio backup o server di test è quasi altrettanto buono dell'accesso in lettura al server reale. (dal momento che le persone non cambiano le password abbastanza spesso)

Inoltre, un account quasi ovunque (a meno che tu non sia un sito bancario) non è così prezioso. Centinaia di migliaia di account, però - ora stai parlando. E anche se una sola scrittura in db potrebbe passare inosservata, in genere verranno notati migliaia di db anomali, in particolare per ogni persona il cui account è stato scritto per non essere in grado di accedere. Inoltre, il cracking della password dell'utente ottiene l'accesso ovunque l'utente abbia utilizzato quella combinazione id / password, che probabilmente includerà siti più preziosi dei tuoi.

Come per lo schema di archiviazione dei record, la ragione principale per archiviare l'output della funzione di hashing della password in un blob che il resto del database non interpreta (a differenza dei campi separati salt e hash ) è che non vuoi codificare il tuo algoritmo di hashing nel tuo database. E se domani volessi cambiare in PBKDF2, o scrypt, o in realtà bcrypt? È meglio lasciare che una funzione di hashing della password controllata con password faccia l'interpretazione che legarsi alle funzioni di hash che si adattano al formato del metodo attuale di hash sale + commodity. Invece, se hai solo un campo per algorithm e un altro campo che è solo "stringa da passare all'algoritmo insieme a una password per vedere se la password è buona" (potresti chiamare questo campo hash o saltNhash ), quindi puoi anche aggiornare gli utenti in modo trasparente mentre eseguono l'accesso.

Per inciso, SHA2 salato è accettabile per la sicurezza delle password se ti trovi in piedi in un servizio web nel 1995. Vent'anni dopo, usa bcrypt o qualcosa di ancora migliore . Gli hash delle materie prime salate (come MD5, o la famiglia SHA *) sono vulnerabili agli attacchi economici basati su GPU, al punto che le tabelle arcobaleno non sono economicamente più efficienti - è più economico eseguire l'attacco del dizionario come necessario piuttosto che mantenere attorno ad un tavolo gigante che è banalmente sconfitto salando comunque.

L'hashing della password è qualcosa che altre persone hanno già elaborato in dettaglio per te. Non si scriverebbe il proprio cripto o il proprio algoritmo di compressione video; non commettere l'errore di ignorare la buona soluzione di fronte a te in cambio di anni di scoperta di casi d'angolo sottili che le persone hanno già progettato per.

Mentre si usa un sale sufficientemente lungo e casuale si impedisce un attacco di precalcolo (es. tavoli arcobaleno ), non lo farà proteggersi da un semplice attacco dizionario sulla password. Considerare lo scenario in cui un utente malintenzionato ottiene una copia del database. Se le password sono appena salate SHA2, potrebbe valere la pena tentare di recuperare un certo numero di password. Questo potrebbe essere fatto calcolando gli hash per le prime 100 password più comuni per ogni sale che viene utilizzato nel database. In alternativa, se un account è mirato, l'attaccante può eseguire un attacco approfondito su quell'hash. L'uso di bcrypt aumenta drasticamente il calcolo, il tempo e il costo monetario dell'esecuzione di tale attacco.

Come sottolineato, l'archiviazione sicura delle password non è di aiuto se l'utente malintenzionato ottiene l'accesso in scrittura alla tabella delle password o al database in generale. Quando ciò accade l'attaccante può usare più attacchi diretti.