如何管理Web应用程序中的密码？
当前在 Web 应用程序中保存用户密码的最先进方法是什么？我正在使用 Java 6 + MySQL。我想到的一些问题是：在应用程序中编码更好还是通过 DBMS 编码更好（这是否相关）？哪种算法被认为是可靠的？数据库中要存储什么？对于这个东西真的很陌生，所以可能错过了一些关键细节，在这种情况下，请随时告诉我。
谢谢。
What is the current state of the art method for persisting users passwords in web applications? I am working with Java 6 + MySQL. Some of the questions I have in mind are: Is it better to encode in the app or by means of the DBMS (is this relevant at all)? Which algorithm is considered to be reliable? What to store in the database? Really new to this stuff, so might have missed some critical details in which case please do not hesitate to let me know.
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您应该将安全散列和加盐版本的密码存储到数据库中。这样，如果您的网站遭到黑客攻击，由于用户几乎在任何地方都使用相同的通行证，因此他们的其他帐户不会受到损害。
为此，应执行以下操作：
在哪里散列密码（应用程序或数据库）并不重要，但数据库的安全散列功能有限，因此应用程序是更好的选择。
You should store securely hashed and salted version of passwords to the database. So that if your site is hacked, since users use the same pass almost everywhere their other accounts are not compromised.
To do this, the following should be done:
It is not important where you hash passwords (App or DB) but DB's have limited secure hashing functionality, so app is the better choice.
bcrypt是一种可靠的密码哈希算法。它是由安全专业人员出于安全考虑而创建的。bcrypt很慢（这是一件好事，使得彩虹表的创建成本非常高）。您可以使用不同数量的轮数来配置 bcrypt，以根据您使用的任何硬件进行扩展（轮数越多 = 速度越慢）。此外，它会自动处理盐生成，每个哈希有不同的盐（这使得彩虹表攻击几乎不可能，因为bcrypt的缓慢性质以及每个哈希需要一个完整的彩虹表的事实密码）。bcrypt的 Java 实现位于 jBCrypt。bcryptis a reliable algorithm for password hashing. It's been created by security professionals with security in mind.bcryptis slow (that's a good thing, makes rainbow tables creation a very costly). You can configurebcryptwith a variable amount of rounds to scale with whatever hardware you are using (more rounds = slower). Also, it automatically handles salt generation, a different salt per hash (which makes a rainbow table attack close to impossible, due to the slow nature ofbcryptand the fact that it would take a full rainbow table per password).A Java implementation of
bcryptis available at jBCrypt.由于提出这样的问题，您将面临许多自称安全专家的愤怒。我本人不是安全专家，但我觉得自己有足够的资格在常识的驱动下提出一些建议。根据您希望应用程序的安全程度，有多种方法。
1- 大多数攻击发生在您通过线路传输凭据时。 （中间的人）。因此，您需要确保用户名和密码的传输是安全的。 （ssl 或 HTTP 摘要）。如果安全性非常重要，那么您应该探索是否需要传递用户名\密码。 （通过使用一些基于令牌的身份验证，如 Oauth，而不是用户名和密码）
2- 如果您决定传递用户名和密码，则需要在应用程序范围内缩短密码字符串的生命周期。当然最好的方法是基于LDAP等机制实现身份验证过滤器。大多数 LDAP 存储将允许您存储加密的密码，并允许您通过绑定执行身份验证。（因此您的应用程序永远不会担心身份验证和存储）
3-当然，如果您确实将密码带到应用程序层您仍然需要缩短明文密码的生命周期并使用某种安全的散列算法进行加密。但这种方法以及将密码存储在数据库中（即使以加密形式）并不是那么安全。 （特别是，由于您存储了密码，因此有人可以绕过您的安全层）
因此，总而言之，根据您需要的安全程度，您需要问自己以下问题。
1-您需要发送用户名/密码吗？
2- 您能否确保密码无法通过网络被嗅探？
3-您能否不将身份验证委托给前端过滤器，而不是带到您的应用程序层？
You are going to face the wrath of, lot of self proclaimed security gurus, for asking an question like this. I myself, is not a security expert, but feel myself qualified enough to put forth some suggestions, driven by common sense. Depending on how secure you want your application to be, there are various methodologies.
1- Most of the attacks happen when you transfer credentials over wire. (Man in the middle stuff). So you need to make sure that the transfer of username and password should be made secure. (ssl or HTTP Digest). If security is very important, then you should explore if the username \ password need to be passed at all. ( by using some token based authentication like Oauth instead of username and password)
2- In case, if you decide to pass in username and password, you need to reduce the lifetime of the password string, in your application scope. Of course the best method is to implement a authentication filter based on a mechanism like LDAP. Most LDAP store, will allow you to store encrypted password and will allow you to perform authentication by binding.( so your application will never worry abt authentication and storing)
3- In case if you do bring your password to your application tier, of course you still need to reduce the lifetime of your plaintext password and encrypt using some secure hashing algorithm. But this approach and storing the password in your database (even in encrypted form) is not all that safe. ( especially, since you are storing the password, someone can circumvent your security layer)
So to summarize, based on the amount of security you need, you need to ask yourself the following question.
1- Should you need to send username / password?
2- Can you make sure that the password cannot be sniffed over the network?
3- Can you not delegate your authentication to a front filter, rather than bringing on to your application tier?