BCrypt hashing della password con l'email dell'utente come salt?

Un bcrypt salt deve essere lungo 128 bit, ecco perché l'uso degli indirizzi email non può funzionare, poiché la loro lunghezza non è fissa.

Inoltre, i sali utilizzati per l'hashing della password devono essere unique . Un indirizzo email, anche se contrassegnato come unico nel database, potrebbe essere utilizzato anche come sale in un altro database su un altro sito Web. Ecco perché dovresti generarne uno a caso.

Poiché i sali non sono segreti, puoi recuperare il sale associato all'indirizzo email con cui l'utente vuole accedere (tramite AJAX), eseguire il primo calcolo di bcrypt e inviare il risultato al server.

Ma non è una buona idea dal punto di vista della sicurezza. Vedi questa domanda capire perché hashing la password lato client non è necessaria.

I sali devono essere globalmente unici

Anche se questo potrebbe non essere applicabile al tuo caso, ci sono buone ragioni per cui i sali non possono essere derivati da un nome utente o da altri dati costanti sull'utente.

Considera un utente Alice che utilizza la stessa password su più siti, entrambi i quali usano il suo nome utente come sale. Ciò porterà allo stesso hash che appare in entrambi. Utilizzare una combinazione di nome utente e sito stesso per il sale dovrebbe rispondere a quella specifica preoccupazione.

Formato sali

Come altri hanno sottolineato, il tuo sale è nel formato sbagliato. È possibile eseguire un hash dell'indirizzo e-mail e del nome del sito e quindi troncare tale hash a 16 byte.

L'hashing del lato server è ancora richiesto

Ci sono alcune cose che l'hashing lato client offre, ma non può mai (beh, quasi mai) essere un sostituto per l'hashing lato server. E a meno che non sia associato ad altre costruzioni utili, l'hashing del lato client non offre davvero molto. Per lo più aiuta a salvare il server un po 'di lavoro.

Il più evidente apparente vantaggio dell'hash del lato client è che rende più difficile per il servizio imparare la password dell'utente poiché la password stessa non viene inviata. Ma quel vantaggio funziona solo con un modello di minaccia molto limitato. È necessario un utente malintenzionato in grado di acquisire il lato server della password quando viene inviato dal client, ma non può modificare il codice JavaScript nella pagina di accesso.

C'è anche una sorta di superamento della mentalità di hash qui. L'hash che il client invia è un segreto. Se viene catturato (diciamo in transito) può essere utilizzato da un utente malintenzionato per accedere al servizio proprio come farebbe la conoscenza della password di origine. Quindi, solo perché l'hash non sembra un segreto (mentre la password di origine lo fa), è una prova di autenticazione.

Non sto dicendo che l'hashing del lato client è inutile, ma è molto meno utile che la gente si aspetta in molte circostanze.