散列 - 加盐和拉伸
在阅读最近的答案时我来到这篇关于密码哈希的有趣博客文章，虽然我已经熟悉其中解释的大多数技术，但我的脑海中突然出现了一些疑问 - 其中最相关的是 < strong>如果我们拉伸（多次散列）我们的散列，为什么加盐很重要？
例如，如果我们采用字符串“password”并应用 SHA-1 散列的 1000 次迭代，我们就会结束使用“862e52b42b26c0f7e2b6ef5f635226bf0fd3f7fb”作为我们的最终哈希值，如果我们只对其进行哈希一次，则与“5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8”非常不同。这些迭代不也算作加盐的一种手段吗？在第二次迭代中，我们已经对 40 个字符长的字符串进行哈希处理，这意味着攻击者必须确定我们使用了多少次迭代（类似地，攻击者也可以猜测我们的秘密盐）或生成所有 1 461 501 637 330 902 918 203 684 832 716 283 019 655 932 542 976 组合 (16^40) 的彩虹表。
有关加盐的其他问题：
- 您使用静态盐还是动态盐（随机数）？为什么？
- 如果您使用随机数，您将它们设置为多大以及将它们存储在哪里（前缀、列……）？
我理解使用随机数相对于静态（长）加盐的额外好处，但我无法想象攻击者可以付出必要的努力来完成成功的暴力匹配的任何场景（我认为他们更有可能发现哈希冲突在那之前）。另外，如果我们使用随机数进行散列，我们需要向数据库发出两个查询，而不是一次（一个查询是为了获取随机数，以便我们可以计算散列，另一个查询是为了检查它）。老实说，我不明白为什么单独伸展运动不被认为是“安全的”。
还有，为什么有这么多人采用SHA> 1 实施? SHA-1 仍然安全吗？新闻应用程序是否应该使用最新的 SHA 实现来散列敏感数据？当仍在使用 MD5 / SHA-1 的“旧”应用程序需要将其哈希值迁移到更新的实现时会发生什么？
Possible Duplicates:
hash(hash()) vs salted hash
Many hash iterations: append salt every time?
While reading a recent answer I came to this juicy blog post about password hashing, and although I was already familiar with most of the techniques explained there, some doubts popped up in my mind - the most pertinent of them is why is salting important if we stretch (hash multiple times) our hash?
For instance, if we take the string "password" and apply 1000 iterations of SHA-1 hashing we end up with "862e52b42b26c0f7e2b6ef5f635226bf0fd3f7fb" as our final hash, very different from "5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8" if we only hashed it once. Doesn't these iterations also count as a mean of salting? At the second iterations we are already hashing a 40 character long string, which means that an attacker has to either know for sure how many iterations we used (similarly an attacker could also guess our secret salt) or generate a rainbow table of all 1 461 501 637 330 902 918 203 684 832 716 283 019 655 932 542 976 combinations (16^40).
Additional questions regarding salting:
- Do you use static or dynamic salts (nonces)? And why?
- If you use nonces, how big do you make them and where do you store them (prefix, column, ...)?
I understand the added benefit of using nonces over static (long) salting, but I can't imagine any scenario where an attacker could put the effort necessary to pull off a successful brute force match (I think it's more probably they find an hash collision before that). Also, if we hash using nonces we need to issue two queries to the database instead of one (one to grab the nonce so we can compute the hash and another one to check it). Honestly, I can't understand why stretching alone isn't considered "secure".
Also, why are there so many people adopting SHA > 1 implementations? Isn't SHA-1 still secure? Should news applications use the newest SHA implementation available to hash sensitive data? What happens when "old" apps still using MD5 / SHA-1 need to migrate their hashes to a more recent implementation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论