密码如何根据哈希和咸密码进行检查？
如果用户创建一个新密码，并且通过哈希算法并将其存储在数据库中，则可以将其登录时与用户输入的密码匹配。将输入的密码放在登录屏幕中，然后检查至看看它是否与存储的哈希相匹配。如果确实如此，则允许用户访问。
但是，如今，密码被哈希和腌制。因此，当用户首次注册其密码时，它会通过哈希进行，然后将其腌制超过10,000次。该盐的盐与后端代码生成的关键字相同，还是每次盐分时都会随机生成？
当用户输入密码登录时，它如何与哈希密码和盐密码匹配，如果每次盐是随机的，那肯定会带有不同的哈希？这就是为什么即使两个用户输入相同的密码，他们最终都会得到不同的哈希。
If a user creates a new password and this goes through a hash algorithm and is stored in the database, it can then be matched up with the user's entered password when they log in. The password entered into the login screen is hashed and then checked to see if it matches the stored hash. If it does, it allows the user access.
However, nowadays, passwords are hashed and salted. So when the user first registers their password, it goes through a hash, and then it gets salted over 10,000 times. Is this salt with the same keyword generated by the backend code, or is it randomly generated for each time it gets salted?
When the user enters the password to log in, how does it match up to the hash and salted password, if the salt is random each time, surely it will end up with a different hash? That's why even if two users entered the same password, they end up with a different hashes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好问题！
盐和哈希单词的实际机制因实施而异。但是，盐背后的总体想法是为每个存储的密码生成一个随机的信息，称为盐。然后，存储的值是从密码本身与盐混合在一起的。可能是您哈希密码，然后运行许多将哈希与盐结合在一起的回合，或者也许您只是将密码和盐连接在一起，然后将其放置很多次。
对于此过程而言，至关重要的是，对于每个密码，您的盐分都不同。如果您每次都使用相同的盐，则在将其散布并将其与盐结合在一起后，同一密码的每个副本看起来都相同。这泄漏了信息，这不是一件好事。
当服务器检查密码时，它需要访问存储密码时使用的盐。否则，它无法重新计算密码中存储的值。盐通常在最后的哈希旁边存储。这个想法是盐不是秘密 - 密码是 - 因此，可以将其存储在并肩上是可以的。
是的，每个密码都用不同的盐存储。每个盐是随机生成的，然后与最终密码哈希一起存储。
Great questions!
The actual mechanics of how salting and hashing words vary from implementation to implementation. However, the general idea behind a salt is to generate, for each stored password, a random piece of information called the salt. The stored value is then derived from a hash of the password itself mixed with the salt in some way. It could be that you hash the password and then run lots of rounds of combining the hash with the salt, or perhaps you just concatenate the password and salt together and hash it lots of times.
It's essential, for this process to work, that you have a different salt for each password. If you use the same salt each time, then every copy of the same password will look the same after you're done hashing it and combining it with the salt. This leaks information, which is not a good thing.
When the server checks the password, it needs to have access to the salt that it used when storing the password. Otherwise, it has no way of recalculating the stored value from the password. The salts are usually stored right next to the final hash. The idea is that the salt isn't the secret - the password is - and so it's fine to just store it alongside.
Yep, each password is stored with a different salt. Each salt is randomly generated, but then stored alongside the final password hash.