java 在 Android App 中使用 jBCrypt 对密码加盐会导致长时间挂起

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

提问by WilHall

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

当他们使用我的应用程序注册时，我正在使用jBCrypt 库来散列用户密码。

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 hangwhen registering, and checked the debugger, confirming BCrypt was responsible.

我在注册时注意到一到两分钟的挂起，并检查了调试器，确认 BCrypt 是负责的。

Does salting the password really take thatmuch 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?

对密码加盐真的需要那么多处理能力吗？如果是这样，一个好的选择是将明文密码发送到服务器进行哈希处理吗？我最初的想法是在它被发送到任何地方之前对其进行哈希处理。有任何想法吗？

回答by Shaun the Sheep

Here is an articlewhich 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.

这是一篇文章，其中列出了在配备 Core 2 Duo 处理器的 Mac 笔记本电脑上花费的时间。所以，是的，Bcrypt 在移动设备上可能会很慢。

Another common problem is the initialization of SecureRandomwhich 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 gensaltseparately to isolate the random data generation and then just time the call to hashpw.

另一个常见的问题是它的初始化SecureRandom可能很慢，也可能由于缺乏足够的随机数据而挂起。这将因不同的机器和操作系统而异。您会在其他地方找到大量有关此问题的讨论，但您可能想要测试自己使用初始化new SecureRandom()或gensalt单独调用以隔离随机数据生成，然后仅对调用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.

因此，如果密码存储在服务器上，则应以明文形式（通过安全通道）发送，服务器应决定如何对其进行散列。