Using jBCrypt to salt passwords in Android App causes a long hang

Question

I am using the jBCrypt Library to hash user passwords when they register using my app.

I am using the basic hash function, with a salt, like so:

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

I noticed a one to two minute hang when registering, and checked the debugger, confirming BCrypt was responsible.

Does salting the password really take that much processing power? If so, would a good alternative be to send the plaintext password out to the server to hash it? My original thought on the matter was to hash it before it got sent anywhere. Any ideas?

Extractor

Well, in a way, bcrypt is designed to do just that. Of course if it causes such a long hang in the client it's not acceptable. – Undernourished

You've tried to run the hashing process on another thread besides the UI? (eg: android.os.AsyncTask) – Chisolm

Answer 1

Here is an article which lists the times taken on a Mac laptop with a Core 2 Duo processor. So, yes, Bcrypt is likely to be very slow on a mobile device.

Another common problem is the initialization of SecureRandom which can be very slow and may also hang due to the lack of enough random data. This will vary between different machines and operating systems. You'll find plenty of discussion of that elsewhere, but it's something you might want to test either initializing it yourself using new SecureRandom() or by calling gensalt separately to isolate the random data generation and then just time the call to hashpw.

Another question is why you actually want to hash it on the client? If you are storing it on the client and logging in locally, then that may make some sense, but if it is being sent to a server and a normal login involves sending a plaintext password to the server then you aren't gaining anything. Also, a common misconception is that hashing a password before sending it to the server (when logging in) offers some protection, when in fact it is equivalent to sending the plaintext password. An attacker only has obtain the hash to be able to gain access.

Hashing passwords is a means of preventing an attacker from gaining access (or at least slowing them down) should the password store itself be compromised.

So if the password is stored on the server, it should be sent in plaintext (over a secure channel) and the server should make the decision on how it is hashed.

Monkfish

The difference between sending a hash of a password from the client to the server and sending the password in plaintext is that if it's intercepted, it's only valid for that domain. Cross-domain compromises (by people reusing the same password on multiple sites) are pretty common. – Lancer

@StevePomeroy BCrypt uses a random salt so in practice you couldn't check the password unless it was stored in plaintext on the server or you sent the salt to the client before it calculated the hash. If you use a secure channel like HTTPS (which you always should) then you don't gain much in terms of protecting against interception in transit. Shared passwords compromises are usually a result of the password database being stolen and being in plain text or hashed using a poor choice of algorithm. – Monkfish