社交网络和 Finacal 数据的密码哈希
可能的重复：
对密码加盐：最佳实践？
我工作的公司正在构建一个社交网络 (就像许多其他人一样）。在开发用户登录系统时，我不确定要使用哪种散列。我知道永远不要使用 md5。我有一种有趣的方式来使用 sha512 和漩涡以及变化的盐。我的老板说他可能希望将用户的财务数据与登录信息相关联。语言是 PHP 只是为了让您知道。
Possible Duplicate:
Salting Your Password: Best Practices?
The company I work for is building a social network (like many other people are). While working on the user login system I was unsure what sort of hashing to use. I know never to use md5. I have an interesting way of working with sha512 and whirlpool and a changing salt. My boss says he may want to have users finacal data connected with there login info. The language is PHP just to let you know.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
无论您做什么，都不要使用您自己的密码哈希函数。你能做的最糟糕的事情就是使用加密原语“以一种有趣的方式工作”。像 bcrypt 这样的算法是由专业密码学家开发和分析的，他们比我、你或 StackOverflow 上的其他人都擅长得多。
当您认为自己正在加强安全性时，却很容易削弱安全性。
另外，对于财务信息，请勿使用您自己的密码哈希函数。这件事很重要，需要说两遍。
Whatever you do, do NOT roll your own password hashing function. The very worst thing you can do is "have an interesting way of working" with crypto primitives. Algorithms like bcrypt have been developed and analysed by professional cryptographers, and they are much better at it than me, you, or just about anyone else on StackOverflow.
It is surprisingly easy to weaken your security when you think you are strengthening it.
Also, for financial information, do NOT roll your own password hashing function. It's important enough to say twice.
我最近看到 Blowfish 被推荐作为密码散列的最佳实践，在其基础是它比 SHA 系列慢，因此它使得暴力猜测攻击不太实用。根据维基百科，OpenBSD 使用它就是出于这个原因。
您还可以考虑实现对 OpenID 的支持，这样用户就不必在您的网站上存储密码根本不。 （这对于社交网络来说是一个很好的可选功能，尽管对于金融网站来说可能不可接受，例如出于监管原因。）
I've recently seen Blowfish recommended as a best practice for password hashing, on the basis that it's slower than the SHA family so it makes brute-force guessing attacks less practical. According to Wikipedia, OpenBSD uses it for this reason.
You might also consider implementing support for OpenID so users don't have to store a password on your site at all. (That'd be a nice optional feature for a social network, though it may not be acceptable for a financial site, e.g. for regulatory reasons.)
有两个明显的事情需要牢记在心，但每个人都喜欢忘记：
密码散列实际上对网站安全本身没有任何影响。这只是针对这样一种假想的情况，即您的用户群被盗并被用于攻击其他地方的相同用户。
任何带有超随机盐的哈希算法都无法保护“joe”、“123”或“password”等愚蠢的密码。或者甚至更复杂的密码，如“v5dsa”。
因此，你要么用强密码要求来折磨你的用户，要么干脆忘记密码哈希这样的愚蠢事情。
或者只是警告他们不要在您的网站上使用相同的密码，您的任务就完成了！
哈希问题在这个网站上被夸大了。
一般所谓的“PHP 程序员”认为，如果他们不使用“损坏”的 MD5（尽管他们不知道这意味着什么），那么他们就是安全的。
可怜的 OP 就是我所说的一个完美的例子：
他正在做两个不同的哈希值并将它们分开存储。认为这将有助于保护他们的网站:)
这就是问题所在。普通用户认为密码哈希与网站安全有关。虽然事实并非如此。
Two obvious things to bear in mind which everyone prefer to forget:
Password hashing actually adds nothing to the site security itself. It's just for such imaginary case when your user base was stolen and used against the same users somewhere else.
No hashing algorithm with super-extra-random salt will protect silly passwords like 'joe', '123' or 'password'. Or even more complex passwords like 'v5dsa'.
So, you have to either torture your users with strong passwords requirement or just forget such a silly matter as a password hashing.
Or simply warn them not to use the same password for your site and your mission accomplished!
Hashing problem is way exaggerated on this site.
An average so-called "PHP programmer" thinks that if they don't use MD5 which is "broken" (though they have no idea what does it mean) - they are safe.
The poor OP is a perfect example of what I am saying:
He is doing 2 different hashes and store them separately. thinking it will help with securing their site :)
That's the problem. An average user is thinking that password hashing has something to do with site security. While it is not.