如何正确存储密码*？

我在SO中偶然发现的一篇文章提供了与其他文章的链接,这些文章反过来提供了更多 文章的链接等.

最后我完全被遗忘了 - 那么在DB中存储密码的最佳方法是什么？从我可以放在一起你应该:

使用长(至少128个完全随机位)盐,它以密码旁边的明文存储;

在salted密码上使用SHA-256的几次迭代(甚至更高的SHA级别).

但是......我读到的关于密码学的内容越多,我就越了解我并不真正理解任何东西,而且我多年来认为真实的东西实际上是错误的.这里有专家吗？

补充:似乎有些人忽视了这一点.我重复上面给出的最后一个链接.这应该澄清我的担忧.

https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2007/july/enough-with-the-rainbow-tables-what-you-need-to-know-about-安全密码的方案/

1> Eyal..：

---

你做对了.只有两个建议:

如果有一天SHA1变得太弱并且您想要使用其他东西,则无法取消旧密码并将其重新与新方案重新使用.出于这个原因,我建议在每个密码上附加一个"版本"号,告诉你你使用了什么方案(盐长度,哪个哈希,多少次).如果有一天你需要从SHA切换到更强的东西,你可以创建新式密码,同时在数据库中仍然使用旧式密码,并仍然分开它们.将用户迁移到新方案将更容易.

密码仍然从用户到系统而没有加密.如果这是一个问题,请查看SRP.SRP是如此新颖,你应该对实现它有点偏执,但到目前为止看起来很有希望.

编辑:原来bcrypt在想法编号1上击败了我.存储的信息是(成本,盐,哈希),其中成本是散列完成的次数.看起来像bcrypt做对了.无需用户干预即可增加散列次数.

---

@Kiff - YAGNI对此有何看法？曾经被认为是强大的哈希已经证明是弱势的(例如MD5),制定一个计划来处理SHA1有缺陷或becomong depricated不是YAGNI,它是从历史中学习.事实上,专家们已经在质疑SHA1.