在 Android 应用程序中使用 jBCrypt 对密码加盐会导致长时间挂起
当用户使用我的应用程序注册时，我使用 jBCrypt 库 对用户密码进行哈希处理。
我正在使用带有盐的基本哈希函数，如下所示：
String pass = BCrypt.hashpw(rawPass, BCrypt.gensalt());
注册时我注意到一到两分钟的挂起，并检查了调试器，确认是 BCrypt 造成的。
加盐密码真的需要那么多处理能力吗？如果是这样，一个好的替代方案是将明文密码发送到服务器进行哈希处理吗？我对此事的最初想法是在将其发送到任何地方之前对其进行哈希处理。有什么想法吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是一篇文章，其中列出了配备 Core 2 Duo 处理器的 Mac 笔记本电脑。所以，是的，Bcrypt 在移动设备上可能会非常慢。
另一个常见问题是 SecureRandom 的初始化，它可能非常慢，并且还可能由于缺乏足够的随机数据而挂起。这在不同的机器和操作系统之间会有所不同。您会在其他地方找到对此的大量讨论，但您可能想要测试一下，要么使用 new SecureRandom() 自己初始化，要么单独调用 gensalt 来隔离随机数据生成，然后只需对
hashpw的调用进行计时。另一个问题是为什么你实际上想在客户端上对其进行哈希处理？如果您将其存储在客户端上并在本地登录，那么这可能有意义，但如果将其发送到服务器并且正常登录涉及向服务器发送明文密码，那么您将不会获得任何内容。此外，一个常见的误解是，在将密码发送到服务器（登录时）之前对密码进行哈希处理可以提供一些保护，而实际上这相当于发送明文密码。攻击者只需获取哈希值即可获得访问权限。
如果密码存储本身受到威胁，哈希密码是一种防止攻击者获得访问权限（或至少减慢访问速度）的方法。
因此，如果密码存储在服务器上，则应以明文形式（通过安全通道）发送密码，并且服务器应决定如何对其进行哈希处理。
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
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 usingnew SecureRandom()or by callinggensaltseparately to isolate the random data generation and then just time the call tohashpw.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.