强制使用复杂的密码“更重要”比腌制？
在过去的两个小时里，我花了两个小时阅读有关加盐密码的内容，以确保我理解这个想法。我希望你们中的一些人能够分享你们对我的结论的了解。
If I'm an attacker, and I gain access to a user database, I could just take all the per-user salts present in the table and use those to create my rainbow tables. For big tables this could take a long time. If I could cut the list down to users of interest (admins, mods) I could use much bigger dictionary lists to create the rainbow tables, raising my percentage of hits...
如果这是真的，那么加盐似乎并没有多大帮助。它只会稍微减慢攻击者的速度。
我知道理想情况下您会想要强制使用复杂的密码并使用独特的随机字符串来加盐，但是强制使用复杂的密码可能会惹恼用户（我知道这会让我烦恼），所以很多网站都不会这样做。网站似乎对此对用户造成了伤害，强制使用复杂的密码比良好的加盐方法重要得多。
我想这与其说是一个问题，不如说是要求其他人了解情况。
I've spent the past 2 hours reading up on salting passwords, making sure that I understood the idea. I was hoping some of you could share your knowledge on my conclusions.
If I'm an attacker, and I gain access to a user database, I could just take all the per-user salts present in the table and use those to create my rainbow tables. For big tables this could take a long time. If I could cut the list down to users of interest (admins, mods) I could use much bigger dictionary lists to create the rainbow tables, raising my percentage of hits...
If this is true then it seems that salting really doesn't do all that much to help. It only marginally slows down an attacker.
I know ideally you would want to force complex passwords and salt them with unique and random strings, but forcing complex passwords can annoy users (i know it annoys me), so a lot of sites don't do it. It seems sites are doing their users a disservice with this, and that forcing complex passwords is a lot more important than a good salting method.
I guess this isn't so much a question, but a request for others knowledge on the situation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
加盐密码和复杂密码对于真正的安全都是必要的。通常，彩虹表不是为了攻击特定站点而动态创建的，而是预先计算的。简单地暴力破解密码比根据特定盐值生成查找表要有效得多。
话虽这么说，哈希的目的是确保如果您的数据库遭到破坏，攻击者无法恢复密码。它无法阻止攻击者猜测简单的密码。
要求密码复杂性实际上取决于您要保护的站点类型/数据类型。它会惹恼一些用户，并导致其他人将他们的密码写在帖子上并将其粘贴到他们的显示器上。我想说，在您的终端上使用强大的哈希和盐是绝对必要的 - 忽视这样做不仅会暴露您的网站，还会完全损害每个回收用户名/密码组合的用户。
因此，在我看来，无论站点的安全级别如何，加盐都是强制性的。强制密码复杂性对于高安全性站点来说是有好处的 - 但肯定更具体。它不能保证用户的良好安全实践。我还要补充一点，要求不需要安全密码的网站弊大于利，因为用户更有可能重复使用在其他更重要的网站上使用的高安全性密码。
Both salted passwords and complex passwords are necessary for real security. Typically rainbow tables aren't created on the fly to attack a specific site, but are rather precomputed. It would be far more efficient to simply brute force a password than to generate a look up table based on a particular salt value.
That being said the purpose of a hash it to ensure that an attacker can't recover a password if your database is compromised. It does nothing to prevent an attacker from guessing an easy password.
Requiring password complexity is really a matter of the type of site/ type of data you are protecting. It will annoy some users, and cause others to write their password out on a post it and stick it to their monitor. I'd say it is absolutely essential to use a strong hash and salt on your end- neglecting to do so exposes not only your site, but completely compromises every user who recycles username/ password combinations.
So in my opinion salting is mandatory regardless of the security level of your site. Enforced password complexity is good for high security sites - but is definitely more situational. It won't guarantee good security practices on the part of your users. I'll also add that requiring a secure password for a site that doesn't require it can do more harm than good as it is more likely that a user will recycle a high-security password that they use on other more essential sites.
salt 的要点是攻击者不能再使用预先存在的字典来攻击系统中的任何用户。他们必须使用该用户的盐为每个用户创建一个全新的字典，这需要时间和精力。如果您在为系统的所有用户创建字典之前了解到违规行为，您就有时间采取行动。 （提醒用户他们的登录凭据必须更改，这应该生成新的随机盐。）
我想说的是，您应该同时使用盐和最复杂的密码（传递短语，真的）你的用户会容忍。即便如此，加盐仍然是一项基本的安全措施，没有它你就无法承受。
The point of a salt is that an attacker can no longer use a pre-existing dictionary to attack any user in your system. They have to create a brand new dictionary for each user using that user's salt, which takes time and effort. If you learn about a breach before dictionaries are created for all users of your system, you have time to act. (Alert users that their log-in credentials must be changed, which should generate a new random salt.)
I would say that you should use both a salt and the most complex password (pass phrase, really) that your users will tolerate. Even still, salting is a fundamental security measure, and you can't really afford to do without it.
保持适当的水分比呼吸更重要吗？
Is keeping properly hydrated more important than breathing?
对于大多数网站，我倾向于使用每个用户一个盐、全局盐（每个算法盐）和适度的密码复杂性规则（8 个以上字符，至少 2 个大写/数字/标点符号字符的组合）的方法。使用盐需要为每个要破坏的帐户生成彩虹表 - 假设每个用户都有唯一的盐。使用全局盐要求您同时损害数据库和应用程序服务器。就我而言，它们始终是两个独立的系统。使用密码复杂性规则有助于防止使用简单、易于猜测的密码。
对于具有更多权限的帐户，您可能希望强制执行更高的密码复杂性。例如，我们的 AD 林中的管理员必须拥有至少 15 个字符的密码。它实际上比较短的密码更容易，因为它几乎迫使您使用密码短语而不是密码。
您还希望指导您的用户如何创建良好的密码，或者更好的是密码短语，并了解各种社交工程攻击，这些攻击会绕过您保护数据的所有技术手段。
I tend to favor an approach that uses a salt per user, global salt (salt per algorithm), and modest password complexity rules (8+ characters with some combination of at least 2 uppercase/digit/punctuation characters) for most web sites. Using salts requires the generation of a rainbow table per account you want to break -- assuming unique salts per user. Using a global salt requires that you both compromise the DB and the application server. In my case, these are always two separate systems. Using password complexity rules helps to protect against simple, easy to guess passwords being used.
For accounts with more privileges, you may want to enforce greater password complexity. For example, admins in our AD forest are required to have a minimum 15 character passwords. It's actually easier than shorter passwords because it pretty much forces you to use a pass phrase rather than a password.
You also want to instruct your users in how to create good password, or better yet, pass phrases and to be aware of various social engineering attacks that circumvent all of your technical means of protecting your data.
好吧，我们来看看真实的数字：
单个 Nvidia 9800GTX 每秒可以计算 3.5 亿个 MD5 哈希值。按照这个速度，小写和大写字母数字字符的整个密钥空间将在 7 天内完成。 7个字符，两个小时。根据您的算法，应用加盐只会使这些时间增加一倍或三倍。
廉价的现代 GPU 很容易拥有每秒 10 亿次 MD5 哈希值。有决心的人通常会连接其中的大约 6 个，每秒获得 60 亿次，使得 9 个字符的密钥空间在 26 天内就过时了。
请注意，我在这里讨论的是暴力破解，因为在这种复杂程度之后，原像攻击可能会也可能不会适用。
现在，如果你想防御专业攻击者，他们没有理由不能每秒获得 1 万亿次哈希，他们只会使用专门的硬件或一些廉价 GPU 机器的农场，以更便宜的为准。
哇，你的 10 个字符的密钥空间在 9.7 天内完成，但 11 个字符的密码需要 602 天。请注意，此时，在允许的字符列表中添加 10 或 20 个特殊字符只会使 10 个字符密钥空间的破解时间分别达到 43 或 159 天。
看到密码散列的问题是它只会减少你徒劳的厄运的时间。如果您想要真正强大的东西，但仍然像存储的散列密码一样简单，请选择 PBKDF2。
那么还有一个问题，用户会在他的所有其他网站上使用你强迫他使用的这个“强”密码吗？如果他不将它们保存在主密码文件中，他肯定会这样做。而那些其他网站不会使用与您使用的相同的强大哈希算法，从而违背了您系统的目的。如果不是为了阻止用户在多个网站上使用相同的密码，我真的不明白为什么您希望哈希值超级强大；如果攻击者可以访问您的哈希值，那么您很可能已经失败了。
另一方面，就像我会重复一遍又一遍地向人们询问他们的散列方案的“安全”程度一样，只需使用客户端证书，所有问题都可以解决。用户不可能在多个站点上使用相同的凭据，攻击者无法在不修改凭据的情况下破坏您的凭据，如果用户将凭据存储在智能卡上，则无法轻易窃取其凭据等。
天真地回答您的问题：强大的凭据密码仅由强大的哈希算法支持。
Okay, let's look at real figures:
A single Nvidia 9800GTX can calculate 350 million MD5 hashes / second. At this rate, the entire keyspace of lower and uppercase alphanumeric characters will be done in 7 days. 7 chars, two hours. Applying salting will only double or triple these times depending on your algorithm.
Cheap modern GPUs will easily boast one billion MD5 hashes / second. Determined people typically link up about 6 of these, and get 6 billion / second, rendering the 9 character keyspace obsolete in 26 days.
Note that I'm talking about brute force here, as preimage attacks may or may not apply after this level of complexity.
Now if you want to defend against professional attackers, there is no reason they can't get 1 trillion hashes / second, they'd just use specialized hardware or a farm of some cheap GPU machines, whichever is cheaper.
And boom, your 10 character keyspace is done in 9.7 days, but then 11 character passwords take 602 days. Notice that at this point, adding 10 or 20 special characters to the allowed character list will only bring the cracking time of a 10 character keyspace to 43 or 159 days, respectively.
See the problem with password hashing is that it only reduces time until your futile doom. If you want something really strong, but still as naive as stored hashed passwords are, go for PBKDF2.
Then there is still one more problem, will the user use this "strong" password you forced him to use on all his other sites? If he doesn't save them in a master password file, he most certainly will. And those other sites wont use the same strong hashing algorithms you use, defeating the purpose of your system. I can't really see why you want your hashes to be super strong if it isn't to stop users from using the same password on multiple sites; if an attacker has access to your hashes, you most likely already lost.
On the other hand, like I will repeat and repeat again to people asking questions about how "secure" their hashing scheme is, just use client certificates, and all your problems are solved. It becomes impossible for users to use the same credentials on multiple sites, attackers cannot break your credentials without modifying them, users cannot easily have their credentials stolen if they store them on a smart card, etc etc.
To naively answer your question: a strong password is only backed by a strong hashing algorithm.
除了长字符串的要求之外，每个约束都会减少密码相空间的大小。约束会导致复杂性降低，而不是增加。
如果这看起来违反直觉，请考虑您正在为破解者提供一堆可靠的假设。让我用我年轻时的一个真实故事来说明这一点：
在双素数加密的早期，处理器速度非常慢，以至于人们倾向于使用 int32 算法来提高速度。这让我可以假设质数在 0 到 40 亿之间。人们总是选择大素数，因为传统观念认为越大越好。因此，我使用了预先计算的素数字典，并从已知的上限开始向下计算，因为我知道人们通常会选择接近该上限的键。这通常让我在大约 30 秒内破解他们的密钥。
坚持使用长密码短语，并使用加盐，没有其他限制。
当人们说“复杂”技术时，他们通常意味着复杂。转换可能非常复杂，但可以交换，不幸的是，如果您不知道这意味着什么，那么您就无法评估该技术的优点。算法的复杂性只能通过默默无闻来提供安全性，这有点像在城外买了一栋房子而不锁门。
With the sole exception of a requirement for a long string, every constraint reduces the size of password phase space. Constraints cause a decrease in complexity, not an increase.
If this seems counterintuitive, consider that you are providing a bunch of reliable assumptions for the cracker. Let me illustrate this point with a true story from my misspent youth:
In the early days of twin-primes encryption processors were so slow that people tended to use int32 arithmetic for speed. This allowed me to assume the primes were between 0 and four billion. People always picked large primes because conventional wisdom held that bigger was better. So I used a pre-computed dictionary of primes and worked down from a known ceiling, knowing that people generally chose keys close to that ceiling. This generally allowed me to crack their key in about 30 seconds.
Insist on long pass phrases, and use salting, with no other constraints.
When people say "sophisticated" techniques they often mean complicated. A transformation can be very complicated and yet be commutative, and unfortunately if you don't know what that means then you're not in a position to assess the merits of the technique. Complexity of algorithm lends only security by obscurity, which is a bit like getting a house out of town and not locking the doors.
使用 salthash 等复杂技术来保证用户私人信息的安全。
但不要妨碍你的用户。提供建议，但不要妨碍他们。
由您的用户选择好的密码。您可以建议如何选择好的密码，接受任何给定的密码，并在给定的密码允许的范围内保证用户信息的安全。
Use sophisticated techniques like salthash to keep your users' private information safe.
But don't obstruct your users. Offer suggestions, but don't get in their way.
It's up to your users to pick good passwords. It's up to you to suggest how to pick good passwords, and to accept any password given and keep the user's information as safe as the password given permits.