Posso inizialmente cancellare le password con SHA invece di eseguirle con bcrypt per disaccoppiare le richieste dalle funzioni di crittografia lente?

Bcrypt viene eseguito molte volte per rallentarlo intenzionalmente. Forse è necessario regolare il numero di cicli di bcrypt in esecuzione? Questa risposta contiene alcune informazioni su di essa.

Sebbene ciò che si propone possa funzionare, non posso dire che l'implementazione di una variante della gestione standard delle password sia una buona idea. Mentre ho preoccupazioni specifiche, come l'hash SHA che rimane nel DB troppo a lungo e la sicurezza della coda crittografata, generalmente non vedo la necessità di variare dallo standard. Se impiega troppo tempo, riduci il numero di round usati per l'esecuzione. Se è inspiegabilmente lento, capire perché. Non limitarti a decidere che puoi fare meglio di decenni di best practice sulla sicurezza. È improbabile che andrà bene.

Forse vuoi pubblicare un'altra domanda (probabilmente su StackOverflow ) chiedendo aiuto per trovare il problema delle prestazioni. Sembra un'idea molto migliore.

Mi dispiace di non essere d'accordo con la tua proposta ...

Il design illustrato comprometterebbe completamente la sicurezza di bcrypt.

Il tuo progetto potrebbe essere semplificato semplicemente eliminando la parte bcrypt del flusso e affidandosi solo all'hash SHA. Questa semplificazione non cambierebbe la sicurezza del design in modo significativo, sarebbe comunque insicuro semplicemente applicando un hash SHA.

L'uso di un hash SHA con un sale sarebbe tuttavia sufficiente per proteggere buone password. Solo le password deboli beneficiano dell'utilizzo di hashing delle password più strong.

Non hai descritto completamente il problema che stai cercando di risolvere, quindi non possiamo fornire alcun consiglio valido su come procedere. Tuttavia, mi vengono in mente due interpretazioni della tua domanda e ciascuna di esse può essere risolta.

Stai tentando di velocizzare la creazione di massa degli utenti?

Se stai cercando di accelerare la creazione di massa di nuovi utenti e di essere rallentato dall'algoritmo di hashing della password, allora posso proporre due modi per migliorare questo caso d'uso specifico.

1. Utilizza password complesse e un hash password mediocre. Se le password generate per gli utenti inizialmente sono forti, non è necessaria la completa sicurezza di bcrypt. Una password iniziale con 128 bit di entropia è passata attraverso un hash della password che fa una singola iterazione salata di SHA-2 è abbastanza sicura. Una volta che l'utente cambia la password iniziale in qualcos'altro, è possibile passare a un algoritmo di hashing della password diverso. Questo può anche essere ottenuto utilizzando formati standard per gli hash delle password, come quello usato una volta dalla funzione crypt , in cui il formato inizia con una specifica dell'hash usato.
2. Utilizza un hash della password che supporta l'hashing iniziale rapido, ma è più lento a verificare le password. Ciò può essere ottenuto applicando un hash SHA-2 alla concatenazione di sale, password e una breve sequenza di bit casuale. Il bitstring casuale non è memorizzato comunque, quindi deve essere forzato bruto per verificare una password. Questa forzatura bruta sostituisce la normale iterazione utilizzata negli hash delle password.

Stai cercando di ridurre il carico della CPU sul tuo server?

Esistono algoritmi di hashing della password che possono scaricare in modo sicuro la parte intensiva della CPU del calcolo sul client senza compromettere la sicurezza. Questo può anche migliorare la sicurezza non consentendo mai al server di vedere la password effettiva. Lo svantaggio di questo approccio è che richiede il supporto lato client. Un cliente non può più inviare solo nome utente e password per accedere.

Quale hash usare?

Non usare nulla di più debole di SHA-2 in nessun nuovo sistema. Eventuali sistemi legacy che utilizzano SHA-1 per l'uso relativo alla sicurezza dovrebbero essere eliminati o aggiornati. Qualsiasi sistema legacy che utilizza MD5 per scopi legati alla sicurezza avrebbe dovuto essere eliminato gradualmente un decennio fa.

La famiglia SHA-2 ha sei diverse varianti. Non andare con una produzione più breve perché pensi che sarà più veloce. In realtà ci sono solo due varianti della funzione di compressione. Uno ha uno stato interno a 256 bit ed è ottimizzato per CPU a 32 bit. L'altro ha uno stato interno a 512 bit ed è ottimizzato per CPU a 64 bit. Se la tua CPU è a 64 bit, allora SHA-512 è il più veloce e probabilmente il più sicuro.

Per l'hashing della password non si dovrebbe mai hash senza sale. Penso che sia l'unico consiglio completamente obiettivo che può essere dato su come usare le password hash. Vi sono molti altri consigli da dare, ma il resto dipenderà dallo scenario delle minacce.

Il rischio è che se un utente malintenzionato riesce a estrarre le password SHA dal database, può eseguire un attacco di indovinamento della password a una velocità relativamente elevata. Almeno dovresti salare queste password, ma allora stai aumentando la complessità che è generalmente in contrasto con la sicurezza. Un buon sistema sicuro dovrebbe essere il più semplice possibile per renderlo tale.

Non penso che bcrypt(sha-2(password)) riduca sicurezza in qualsiasi modo significativo . Sì, potresti ridurre lo spazio di ricerca da 576 bit a 256 (con SHA-256), tuttavia hai bisogno solo di 128 bit di entropia per avere una password "indistruttibile" utilizzando la tecnologia odierna (e quella del futuro prevedibile). Quindi questo è un punto controverso.

Non dimenticare che per convalidare le password per l'accesso devi SHA-2 (veloce) e poi bcrypt it (slow) ogni volta per il confronto. Pertanto il tuo sistema di accesso sarà lento, anche se qui stai facendo bcrypt piuttosto che n * bcrypt , che penso dove il tuo problema si trova con il processo batch.

Penso che la soluzione a questo sia un problema di architettura di sistema piuttosto che un problema di sicurezza. Ottimizza il tuo costo in bcrypt in modo che ci voglia circa 1 secondo per un utente valido per accedere. Quindi ridisegnare il processo batch in modo che sia asincrono e crittografa le password in background. Avere un evento di notifica per restituire se questo processo è andato a buon fine o meno, e se non gli ID utente hanno avuto errori. Ciò migliorerà la tua esperienza utente, rendendo meno sicuro il tuo sistema. La memoria è molto più sicura del DB.