加盐哈希值和密码历史记录
想知道每次更改密码时盐对于单个给定用户是否是唯一的是否重要，或者每次重复使用相同的盐是否没什么大不了的。
目前，每次给定用户更新密码时，我都会生成一个新的随机字符串作为盐。这样，每次用户拥有新密码时，他们的盐也会发生变化。这很容易做到，所以为什么不呢。
嗯...这就是原因。我需要存储以前的 X 个密码以确保密码不会被重复使用。在过去（我上次为此编写代码时），我可以只存储以前的 MD5 哈希值，并将新的哈希值与该列表进行比较。好吧，现在我使用加盐哈希，其中盐每次都是唯一的，这些比较不再可能，因为以前的盐不再已知。
为了使该系统正常工作，我有两个选择：除了最终哈希值之外还存储盐的历史记录，或者在每次密码更新时为任何给定用户重复使用相同的盐。这些都可以让我建立可以与历史相比较的价值观。
后者虽然工作量少了，但会不会失去力量呢？从实际的角度来看，我不认为它确实如此。我想我会在这里得到第二意见。谢谢。
为了保持问题“可回答”——对任何一个用户重复使用相同的盐是否会减少可接受的最小保护，以维护可搜索的密码历史记录（以防止 pswd 回收）？
Wondering whether it matters if a salt is unique for a single given user each time the password is changed, or whether it's not a big deal to reuse the same salt each time.
I currently generate a new random string as the salt each time a given user updates the password. This way each time the user has a new password their is also a salt change. It's easy to do, so why not.
Well... here's why. I need to store the previous X passwords to ensure a password is not reused. In the old days (the last time I wrote code for this), I could just store previous MD5 hashes, and compare new ones to that list. Well, now that I am using salted hashes where the salt is unique each time, those comparisons are no longer possible as the previous salts are no longer known.
To make that system work, I have two choices: store a history of the salts in addition to the final hashes, or reuse the same salt for any one given user with each password update. Either of these would allow me to build values that could be compared to a history.
The latter is less work, but does it lose any strength? From a practical standpoint, I don't see that it does. Thought I'd get a second opinion here. Thanks.
To keep the question "answerable" -- would reusing the same salt for any one user have an acceptably minimal reduction of protection in order to maintain a searchable password history (to prevent pswd recycling)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
重复使用相同的盐意味着，如果用户明确成为黑客的目标，他们可以使用“用户的盐”生成“密码到哈希”字典 - 这样即使用户更改了密码，黑客仍然会立即知道新密码，无需任何额外工作。
我每次都会用不同的盐。
至于存储 MD5 哈希值加盐 - 大概您已经存储盐+哈希值，以便验证用户的当前密码。为什么不能保留完全相同的信息以进行历史检查？这样您就可以使用一段代码来进行密码检查，而不是分离当前路径和历史路径。他们正在做同样的事情，所以他们使用相同的代码是有意义的。
编辑：为了解释我的意思，考虑在密码前面添加一个 4 字符的盐...并且为了论证，假设有人在其密码（和盐）中仅使用 AZ、az 和 0-9。
如果您事先不知道盐（在准备字典攻击时），那么为了为所有 8 个字符的“人类”密码准备字典，您需要对 62^12 个串联密码进行哈希处理。但是，如果您始终知道连接密码的前 4 个字符是什么（因为您提前知道盐），那么您可以只对 62^8 个值进行哈希处理 - 所有这些值都以盐开头。它使得盐对于这种特定的攻击毫无用处。
当然，这仅适用于目标用户 - 并且仅当攻击者可以在密码更改之前和之后获取哈希列表时。它基本上使得更改密码作为安全措施的有效性降低。
Reusing the same salt means that if a user is explicitly targeted by a hacker, they could produce a "password to hash" dictionary using "the user's salt" - so that even if the user changes their password, the hacker will still immediately know the new password without any extra work.
I'd use a different salt each time.
As for storing the MD5 hash plus salt - presumably you're already storing the salt + hash, in order to validate the user's current password. Why can't you just keep that exact same information for historical checks? That way you can use one piece of code to do the password checking, instead of separating out the current and historical paths. They're doing the same thing, so it makes sense for them to use the same code.
EDIT: To explain what I mean, consider a 4 character salt, prepended to the password... and for the sake of argument, imagine that someone only uses A-Z, a-z and 0-9 in their password (and the salt).
If you don't know the salt ahead of time (when preparing a dictionary attack) then in order to prepare a dictionary for all 8 character "human" passwords, you need to hash 62^12 concatenated passwords. If, however, you always know what the first 4 characters of the concatenated password will be (because you know the salt ahead of time) then you can get away with only hashing 62^8 values - all those beginning with the salt. It renders the salt useless against that particular attack.
This only works with a targeted user of course - and only if the attacker can get at the hash list both before and after the password change. It basically makes changing the password less effective as a security measure.
在密码哈希中使用盐的另一个原因是隐藏两个用户使用相同密码的事实（这并不罕见）。使用不同的哈希值，攻击者将看不到这一点。
Another reason for using salt in password hashes is to hide the fact that two users use the same password (not unusual). With different hashes an attacker won't see that.
首先，停止使用MD5（如果你正在使用它），并使用SHA-2、MD5、SHA-0和SHA-1，这些都是死哈希。
-- 编辑：
我现在同意 Jon Skeet 的观点，并建议您考虑在每次更改密码时生成新的盐。它涵盖了一种小情况，攻击者可能会获得盐+哈希，然后无法再次获得访问权限，但仍然允许他（对如何组合它们进行一些猜测）计算所有未来的哈希值密码。它非常小，但也不是那么重要，因为密码大小需要非常小（例如 8 个字符），以便离线计算它们才能实用。但它确实存在。
其次，要考虑它是否重要，我们需要考虑盐的用途。这是为了防止对仅拥有完整密码列表的人进行离线攻击。
在此基础上，如果在密码更改之前和之后获得盐同样“困难”，我认为没有使用新的盐（它与以前一样有风险）。它增加了额外的复杂性，而实现复杂性是大多数安全问题发生的地方。
Firstly, stop using MD5 (if you are using it), and use SHA-2, MD5, SHA-0, and SHA-1, are all dead hashes.
-- Edit:
I now agree with Jon Skeet, and suggest you consider generating a new salt with each password change. It covers a small case where the attacker may get the salt+hash, then not be able to gain access again, but will still allow him (with some guessing of how you combine them), to calculate what the hashes could be for all future passwords. It's very small, and is not so important, because the password sizes will need to be significantly small (say, 8 chars) for even calculating them all offline to be practical. Yet it exists.
Secondly, to consider whether or not it matters, we need to think about the purpose of salts. It is to prevent offline attacks against someone who has a complete listing of only the passwords.
On this basis, if the salt is equally "difficult" to obtain before and after password changes, I see no use a new salt (it's just as at-risk as it was before). It adds additional complexity, and in implementing complexity is where most security problems occur.
我可能在这里非常昏暗，但是，您将在哪里存储那些有足够访问权限来获取散列密码的人无法访问的盐。
I might be being incredibly dim here, but, where would you store the salt that would be inaccessable to someone with enough access to get the hashed password.