Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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?

like image 386
WilHall Avatar asked Oct 02 '11 14:10

WilHall


People also ask

Do I need to store bcrypt salt?

You do not need to store anything else yourself, this information is everything bcrypt needs to hash and compare an incoming password. The actual hash was computed by combining the password and salt, so no worries there.

What is bcrypt salt rounds?

With "salt round" they actually mean the cost factor. The cost factor controls how much time is needed to calculate a single BCrypt hash. The higher the cost factor, the more hashing rounds are done. Increasing the cost factor by 1 doubles the necessary time.


1 Answers

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.

like image 116
Shaun the Sheep Avatar answered Sep 22 '22 14:09

Shaun the Sheep