L'uso di jBCrypt per salare le password nell'app per Android causa una lunga sospensione

Question

Sto utilizzando lo jBCrypt Library alle password utente hash quando si registrano utilizzando la mia app.

sto usando la funzione di base di hash, con un sale, in questo modo:

String pass = BCrypt.hashpw(rawPass, BCrypt.gensalt()); 

ho notato un 1-2 minuti di appendere al momento della registrazione, e controllato il debugger, confermando bcrypt era responsabile.

La salatura della password richiede veramente lo di quella potenza di elaborazione di? In tal caso, una buona alternativa sarebbe quella di inviare la password in chiaro al server per cancellarla? Il mio pensiero originale sull'argomento era di cancellarlo prima che venisse inviato ovunque. Qualche idea?

Answer 1

Questo è il numero an article che elenca i tempi registrati su un laptop Mac con un processore Core 2 Duo. Quindi, sì, Bcrypt rischia di essere molto lento su un dispositivo mobile.

Un altro problema comune è l'inizializzazione di SecureRandom che può essere molto lento e può anche bloccarsi a causa della mancanza di dati casuali sufficienti. Questo varierà tra macchine diverse e sistemi operativi. Ne troverai molte discussioni altrove, ma potresti provare a inizializzarlo utilizzando new SecureRandom() o chiamando lo gensalt separatamente per isolare la generazione casuale dei dati e quindi solo la chiamata allo hashpw.

Un'altra domanda è perché in realtà si desidera eseguire l'hash sul client? Se lo si sta memorizzando sul client e si effettua l'accesso localmente, questo potrebbe avere un senso, ma se viene inviato a un server e un normale login comporta l'invio di una password in chiaro al server, non si ottiene nulla. Inoltre, un malinteso comune è che l'hashing di una password prima di inviarlo al server (al momento del login) offre una certa protezione, quando in realtà equivale all'invio della password in chiaro. Un utente malintenzionato ha solo ottenuto l'hash per poter accedere.

Le password di hashing sono un mezzo per impedire a un utente malintenzionato di accedere (o almeno di rallentarlo) se la memorizzazione della password stessa viene compromessa.

Quindi, se la password è memorizzata sul server, deve essere inviata in testo normale (su un canale protetto) e il server deve prendere la decisione su come è stato sottoposto a hash.