security - 如何为旨在保护密码的哈希函数选择盐？

Question

我是一个(近乎完整的)初学者，这是我第一次涉足加密领域——事实上，这可能是我第一次使用这个词。

这是我的问题:对于非银行/军事甚至商业网络应用程序，为用于密码的哈希函数选择盐的正确方法是什么？

我可以轻松地为每个新用户生成一个伪随机盐，并在应用散列函数之前将该盐附加到他们的 pw 中。但是我仍然需要存储盐，所以大概任何可以访问散列密码的人也会得到盐。

盐的好处仅仅是让 pw “更随机”，从而打败标准的基于字典的彩虹表吗？

以下任何一个都是好的和实用的想法:

将盐存储在单独的数据库中 - 可能是单独的系统，肯定是不同的主机、名称、密码等。

根据用户名(或名字+姓氏，或注册日期)的哈希生成盐，大概使用不同的哈希函数？那么盐本身就不会存储在数据库中——只有用于计算它的数据才会......

在数据库中存储一个值，该值以不明显的方式连接散列 pw 和 salt(例如，salt 是 10 个随 secret 钥，它们被注入(inject)到字母数字 1&2、4&5、8&9 等之间的散列 pw 中)。

作为一个附带问题，在升级网站软件时更改加盐哈希算法有多容易？现在感觉好噩梦。

Answer 1

是的，盐只是为了防止对散列密码的彩虹攻击。通常我对所有密码都使用一个盐值。它存储在我的源代码或配置中，因此不在数据库中。但是为每个用户使用不同的盐可能会更好。这样，具有相同密码的两个用户将不会获得相同的哈希值。

您可以简单地将盐与密码一起存储在数据库中。盐的目的是你不能预先计算彩虹表。这将花费太多时间。比简单地直接暴力破解密码更多时间。即使知道盐，也必须生成该盐的完整彩虹表，这非常昂贵。因此，盐是否已知并不重要。

只要确保盐足够长，如何挑选盐并不重要。根据 Wikipedia 的说法，12 位散列(旧的 unix 密码使用)的破解成本非常高，但有可能。在可预见的将来，128 位(例如 MD5 所使用的)太昂贵而无法取消。

另见:http://en.wikipedia.org/wiki/Rainbow_table#Defense_against_rainbow_tables