md5 哈希使用密码作为盐？

Question

md5($password.md5($password))

这对于密码散列来说足够好吗？我并不是要求将其与 bcrypt 之类的东西进行比较。

如果不安全，请告诉我原因。

Answer 1

为每个用户的密码使用不同的盐的原因是，攻击者无法获取所有散列密码的列​​表，并查看其中是否有任何一个与“密码”或“12345”等简单内容的散列相匹配。如果您使用密码本身作为盐，那么攻击者可以计算 md5("12345".md5("12345")) 并查看它是否与任何条目匹配。

据我了解，您可以在密码表上使用四个级别的散列：

1. 无 - 将密码存储为纯文本。如果有人获得您数据库的副本，他们就可以访问所有帐户。纯文本不好，好吗？
2. 对密码进行哈希处理 - 存储密码的哈希值，并丢弃真实密码。如果有人获得您数据库的副本，他们将看不到任何密码，只能看到哈希值。 但是，如果任何用户使用了弱密码，那么他们的哈希值将出现在彩虹表中。例如，如果用户的密码为“password”，则存储在数据库中的 md5 哈希值将为“5f4dcc3b5aa765d61d8327deb882cf99”。如果我在彩虹表中查找该哈希，例如 gromweb.com 上的哈希，它会吐出出“密码”。
3. 使用盐值 - 选择一个大的随机字符串（例如 GUID）并将其存储在配置文件中。在计算哈希值之前，将该字符串附加到每个密码。现在，彩虹表不太可能起作用，因为它可能没有“password59fJepLkm6Gu5dDV”或“picard59fJepLkm6Gu5dDV”的条目。尽管预先计算的彩虹表不再有效，但如果攻击者知道您的盐值，您仍然可能容易受到影响。攻击者可以计算弱密码加上您的盐的哈希值，并查看数据库中的任何用户是否使用该弱密码。如果您有数千个用户，那么每次哈希计算都会让攻击者进行数千次比较。您实际如何使用盐可能取决于您使用的加密算法。为简单起见，只需将其想象为将盐和密码附加在一起。
4. 使用不同的盐值 - 现在您可以获取一些不同的内容，例如用户名、电子邮件地址甚至用户 ID，然后将其与密码以及配置文件中的大随机字符串组合起来计算哈希值。现在，知道您的盐的攻击者仍然必须重新计算每个用户的哈希值，以查看他们是否使用了“password”等弱密码。

有关更多详细信息，请查看编码恐怖帖子“您可能错误地存储了密码”。

Answer 2

虽然这对我来说似乎已经足够了，但如果有人基于相同的算法预先计算了彩虹表（这是很有可能的），那么它将面临危险。
所以，我宁愿使用电子邮件来获取盐，这看起来非常安全但可用。偏执狂可能会添加一些恒定的全站盐。

人们经常对密码盐（理论上）过于重视，而在他们的应用程序中，他们允许简单的密码，并在实践中通过不安全的 HTTP 以纯文本形式传输它们。

每一天我都会看到有关盐或哈希的问题。
并且没有一个关于密码复杂性的问题。而

您唯一关心的应该是密码复杂性。

为什么？让我告诉你。

极好的盐+弱密码=几秒钟内即可破解

总是假设攻击者知道盐。因此，通过使用一些最常用密码的字典并向其中添加[任何超随机超长]盐，可以在几秒钟内发现弱密码。暴力破解短密码也是如此。

合理的盐 + 强密码 = 牢不可破 相当

独特的盐使预先计算的表毫无用处，而好的密码则使字典和暴力攻击毫无用处。

Answer 3

它对字典攻击没有多大作用，计算字典的难度只是单个 md5 的两倍，而且现在 md5 相当便宜。

Answer 4

MD5 本身并不安全，因为它被部分破坏（冲突）并且摘要太小。如果您不想使用 bcrypt、scrypt 或 PBKDF2 等正确的密码派生函数，您可以新设计至少应使用 SHA-256（并计划在 SHA-3 推出时迁移到 SHA-3，因此请务必存储用于散列密码的方案和结果，以便这两种方案可以共存当人们更改密码时，您将使用新的哈希过程）。

如果您打算以任何身份使用 MD5 来销售您的程序，则可能会成为大多数政府销售的障碍（例如，在美国，使用的算法必须经过 FIPS 140-2 批准，许多其他国家/地区也有相同的要求）。

Answer 5

建议使用随机密码盐对密码进行哈希处理，以便知道密码哈希的攻击者无法将其与

如果您使用密码作为盐，攻击者可以首先从他们的字典中预先计算 $word.md5($word) 的哈希值

Answer 6

通过您的解决方案，您几乎无法实现使用盐来对抗预先计算的字典攻击的目的。

对于预先计算的字典，顾名思义，有人已经提前为特定单词创建了一个哈希表（计算的 md5 结果）。

考虑这个表hashtable（带有虚构的哈希值，仅用于说明目的）

word | hash
------------
foo  | 54a64
bar  | 3dhc5
baz  | efef3

针对您的表测试这些值可能很简单：

SELECT h.word
FROM hashtable h, yourtable y
WHERE y.password = MD5( CONCAT( h.word, h.hash ) );

通过匹配，您就拥有了密码。

但是，如果您没有对密码进行哈希处理，那么在将其与密码再次连接并再次进行哈希处理之前，使用预先计算的字典来攻击它会更加困难。因为这样的话，如果预计算表只考虑了单词的单个实例，那么密码将是例如 md5( 'testtest' ) ，这使得预计算表毫无价值。

您可以很容易地看到，如果您不使用密码作为盐，而是使用另一个随机字符串作为盐，事情会变得更加困难。当您为每个密码创建唯一的盐时，事情会变得更加困难。当然，如果您为每个密码创建唯一的盐，则必须将盐与数据库行中的密码一起保存在单独的列中。

所以我的建议是：

md5( 'uniquesalt' . 'password' );

或者实际上，根本不使用 md5，而是使用更好的 sha1、sha256 （或更高版本）哈希算法。