在 Android 应用程序中使用 jBCrypt 对密码进行加盐会导致长时间挂起

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?

解决方案

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.