我正在寻求有关如何使用 PHP 在 MySQL 中安全存储密码的建议。
忽略 PHP 本身的局限性，我想了解更多关于加盐、散列和加密这些坏孩子的信息。
显然，人们会继续使用弱密码，除非被迫这样做，但对我来说重要的是我存储它们的方式。我的用户密码对我来说比数据库本身重要得多，因此我希望以这样的方式保存它们，对于任何尝试逆向的脚本小子来说，这将是艰苦而单调的。显然，通过尽职调查，几乎任何事情都可以被击败，但我不介意让这变得特别麻烦。
我们正在考虑两种情况。
- 小孩子有数据库的完整副本。
- 这个孩子拥有用于制作密码的 PHP 的完整副本和数据库。
非常感谢有关此主题的任何和所有建议。
I am seeking advice on how to securely store passwords in MySQL using PHP.
Overlooking the limitations of PHP itself, I want to know more about salting, hashing, and encrypting these bad boys.
Obviously people will continue to use weak passwords unless forced to do otherwise, but it's how I am storing them that is important to me. My user's passwords are far more important to me than the database itself, and as such I want to keep them in such a way that it will be painstaking and monotonous for any script kiddie trying reverse. Obviously with due diligence just about anything can be defeated, but I wouldn't mind making this particularly bothersome.
There are two scenarios we are looking at.
- The kiddie has a complete copy of the database.
- The kiddie has a complete copy of the PHP used to craft the password, and the database.
Any and all advice on this topic is graciously appreciated.
发布评论
评论（6）
使用
bcrypt。如果有人拥有您数据库的用户表，那么他们可以随心所欲地使用暴力/彩虹表/等。即使使用 salt，如果您使用 MD5 或其他一些快速哈希算法（顺便说一下，这些算法并不是为了解决这个问题而设计的）；被破解只是时间问题。任何众所周知且广泛支持的哈希算法都会有同样的基本“缺陷”（如果你可以这样称呼它；它确实是根据定义）。不同之处在于，
bcrypt在执行哈希操作时慢如糖蜜，导致暴力攻击的效果要低得多。有关 bcrypt 的优点、其他方法的危险以及一般密码安全难度的精彩讨论，请阅读 此帖子。它有很多人的评论，他们对这类事情的了解比我丰富得多，希望它能帮助您了解更多相关问题。
Use
bcrypt. If someone has the user table of your database, then they can use brute force/rainbow tables/etc to their heart's content. Even with salt, if you're using MD5 or some other fast-hashing algorithm (which aren't designed to solve this problem, by the way); it's just a matter of time before it can be cracked.Any well-known and widely-supported hashing algorithm is going to have this same basic "flaw" (if you can call it that; it's really by definition). The difference is that
bcryptis slow as molasses when performing the hashing operation, rendering a brute force attack much less effective.For an absolutely great discussion on the merits of
bcrypt, the dangers of other approaches, and the difficulty of password security in general, read this thread. It has lots of comments by many people that are much more knowledgeable about this sort of thing than I am, and it should hopefully help you understand more of the issues at stake.假设您使用用户名和密码作为身份验证令牌，您可以安全地存储以下内容以确保数据不会受到损害。
使用该方案，攻击者无法使用 彩虹表对您不利，并且密码无法通过任何（合理）方式恢复。 （也就是说，只要你的攻击者不是政府）
即使攻击者拥有盐和哈希对，也不可能使用彩虹表，因为无论如何都需要使用他们的盐来计算所有可能的哈希值。已经给出，所以这对每个用户来说都是一次全新的暴力攻击。
即使有了源代码，攻击者也无法获得密码，因为强度/安全性在于哈希算法，而不是您的代码。
根据 Donut 的答案，将其与使用 bcrypt 结合起来，你就真的相当安全。即：
Assuming you're using username and password as authentication tokens you can safely store the following to ensure the data can't be compromised.
Using the scheme, an attacker cannot use rainbow tables against you and the passwords are not recoverable by any (reasonable) means. (That is, as long as your attacker isn't the government)
Even though the attacker has the salt and hash pairs it's not possible to use rainbow tables because all the possible hashes will need to be computed anyway, using the salt that they've been given, so it's a brand new brute force attack for each user.
Even with the source code and attacker won't be able to get hold of the passwords because the strength/security is in the hashing algorithm, not your code.
Combine this with using bcrypt as per Donut's answer and you're really quite safe. That is:
从此处，为了增加乐趣，您还可以动态更改盐。例如，对不同长度的用户名使用不同的盐，使用用户的注册日期作为盐。这使得即使有人访问您的数据库，他们也不能只是重新生成哈希，他们必须为您使用的每种盐计算哈希表。
Taking advice from here, for added fun you can dynamically change your salt as well. For example, use different salts for usernames of different length, use the user's registration date as the salt. This makes it that even if someone DOES get to your database, they can't just re-generate the hash, they have to calculate a hash table for each salt that you used.
如果您的用户通过互联网，OpenId 将是您的最佳选择之一。 http://openid.net/
如果您的用户在您的网络上，您可以进行集成安全吗？
换句话说..不要存储他们的密码。
If your users are over the internet, OpenId would be one of your best options. http://openid.net/
If your users are on your network, can you do Integrated Security?
In other words.. do not store their passwords.
通常“加盐”密码（如 bcrypt）意味着不会存储密码本身，而只会存储类似
现在的内容，如果孩子拥有您的数据库（当然还有代码 - 保持代码秘密是没有意义的），他/她只能猜测密码、计算加盐哈希并进行比较。如果哈希函数很昂贵（就像 bcrypt 一样），那么猜测也很昂贵。
Usually "salted" passwords (like with bcrypt) mean that not the password itself is stored, but only something like
Now if the kiddie has your database (and of course, the code - there is no point in keeping the code secret), he/she can only guess passwords, calculate the salted hash, and compare. If the hash function is expensive (like bcrypt is), than guessing is expensive too.
这很简单
，没有人能够逆转它:)
另请参阅：https://stackoverflow .com/questions/3897434/password-security-sha1-sha256-or-sha512
It's simple
And nobody will be able to reverse it :)
See also: https://stackoverflow.com/questions/3897434/password-security-sha1-sha256-or-sha512