Deve essere prima notificato che l'hashing della password è un seconda linea di difesa . Memorizzi nel database del tuo server qualche valore che permetta la verifica della password; il tuo primo dovere non è permettere agli estranei di prendere una copia di quel valore. Quindi, prima applica tutti gli aggiornamenti di sicurezza per il tuo software; sviluppare codice con grande cura e metodologia appropriata (ad es. quando si accede al database, utilizzare le istruzioni preparate ); e attenzione alle procedure operative (non lasciare i backup incustoditi, distruggere i dischi rigidi al momento della rimozione delle autorizzazioni e così via).
L'hashing lento è pensato per rendere l'attività più difficile per l'aggressore nel caso in cui riesca ancora a dare un'occhiata al tuo database. Sfortunatamente, questo rende l'elaborazione delle password più difficile anche per te, quindi questo è un compromesso. Con bcrypt, un fattore di lavoro di n significa che esistono 2 iterazioni interne n ; un fattore di lavoro di "10" significa che hai reso gli attacchi di dizionario circa mille volte meno efficienti (dal 2 10 = 1024). A seconda del tuo outlook, questo può essere grande o insufficiente, ma questo è ancora non trascurabile.
Per migliorare le cose, ci sono vari metodi che puoi prendere in considerazione:
-
Usa un "pepe", cioè una chiave segreta estesa a tutto il server; questo trasforma l'hashing della password in un MAC . Fondamentalmente, quando si "hash la password" (al momento della registrazione e previa verifica), si calcola HMAC / SHA-256 tramite la password, codificare l'output a 32 byte in Base64 (in modo che diventi una bella stringa di caratteri stampabili), quindi usa quella stringa come input per bcrypt.
Questo processo migliora la sicurezza supponendo che l'autore dell'attacco possa ottenere una copia delle password con hash ma non dell'intero server (ad esempio, l'autore dell'attacco potrebbe eseguire alcune operazioni di SQL injection ma non leggere i file di configurazione del server). In particolare, non conservare la chiave nel database stesso.
-
Aiuta gli utenti a scegliere password più forti. Attenti alle parole: ho detto "aiuto", non "forza". In particolare, NON cercare di applicare le "regole di complessità della password" come richiedere un mix di ideogrammi maiuscoli, minuscoli e sumerici. Tali regole, in pratica, non rendono più forti le password; fanno semplicemente arrabbiare gli utenti. Invece, una buona cosa sarebbe quella di offrire uno strumento generatore che produca password ad alta entropia ma facili da memorizzare (vedi questa domanda per l'orientamento). È importante che lo strumento sia facoltativo perché vuoi che gli utenti cooperino liberamente con la tua strategia di sicurezza; se fai qualcosa di obbligatorio allora si ribellerà e le cose andranno peggio.
-
Scarica il problema nelle mani di qualcun altro. Ciò significa autenticare gli utenti attraverso qualcosa come OpenID ; il provider OpenID è un sistema esterno che gestisce la verifica della password per te.
Un esempio degno di nota è StackExchange stesso: sebbene possano gestire da soli la registrazione e la verifica della password, ti consentono anche di registrarti utilizzando il tuo account Google o Facebook esistente o qualsiasi altro provider OpenID.
-
Acquista un server più grande e più potente.