多次加密（MD5）可以提高安全性吗？

发布于 2024-11-27 01:37:19 字数 63 浏览 5 评论 0 原文

我看到有人用 MD5 对用户密码进行多次加密以提高安全性。我不确定这是否有效，但看起来不太好。那么，这有意义吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

冰魂雪魄 2024-12-04 01:37:19

我们假设您使用的哈希函数是一个完美的单向函数。然后你可以像"random oracle"一样查看它的输出，它的输出值在一个值的有限范围（MD5 为 2^128）。

现在，如果多次应用哈希会发生什么？输出仍将保持在相同范围内 (2^128)。就像你说“猜猜我的随机数！”二十次，每次都想一个新的数字——这并不会让猜测变得更难或更容易。没有比随机更“随机”的了。这不是一个完美的类比，但我认为它有助于说明问题。

考虑到暴力破解密码，您的方案根本不会增加任何安全性。更糟糕的是，您唯一可以“完成”的事情就是通过引入一些利用哈希函数重复应用的可能性来削弱安全性。虽然可能性不大，但至少可以保证你不会赢得任何东西。

那么为什么这种方法仍然没有迷失呢？这是因为其他人提出的想法是进行数千次迭代，而不是仅仅 20 次。为什么这是一件好事，可以减慢算法速度？这是因为大多数攻击者会尝试使用字典（或使用常用密码的 rainbow 表来获取访问权限，希望你的一个用户疏忽大意地使用了其中一个（我有罪，至少 Ubuntu 在安装时告诉我），但另一方面，要求你的用户记住 30 是不人道的。。

这就是为什么我们需要在易于记住的密码和同时让攻击者尽可能难以猜测之间进行某种形式的权衡。有两种常见的做法，salts 并通过应用某些函数的大量迭代而不是单次迭代来减慢进程。

href="http://www.rsa.com/rsalabs/node.asp?id=2127" rel="noreferrer">PKCS#5 是您应用 MD5 20000 的而不是 20 次，会显着降低攻击者使用字典的速度，因为他们的每个输入密码都必须经过哈希 20000 次的普通过程，才能仍然作为攻击有用。请注意，此过程不会影响如上所示的暴力破解。

但为什么使用盐更好呢？因为即使您应用哈希 20000 次，足智多谋的攻击者也可以预先计算大型密码数据库，对每个密码进行哈希 20000 次，从而有效地生成专门针对您的应用程序的自定义彩虹表。完成此操作后，他们可以很容易地攻击您的应用程序或使用您的方案的任何其他应用程序。这就是为什么您还需要为每个密码生成较高的成本，以使此类彩虹表使用起来不切实际。

如果您想真正安全，请使用 PKCS#5 中所示的 PBKDF2 之类的东西。

Let's assume the hash function you use would be a perfect one-way function. Then you can view its output like that of a "random oracle", its output values are in a finite range of values (2^128 for MD5).

Now what happens if you apply the hash multiple times? The output will still stay in the same range (2^128). It's like you saying "Guess my random number!" twenty times, each time thinking of a new number - that doesn't make it harder or easier to guess. There isn't any "more random" than random. That's not a perfect analogy, but I think it helps to illustrate the problem.

Considering brute-forcing a password, your scheme doesn't add any security at all. Even worse, the only thing you could "accomplish" is to weaken the security by introducing some possibility to exploit the repeated application of the hash function. It's unlikely, but at least it's guaranteed that you for sure won't win anything.

So why is still not all lost with this approach? It's because of the notion that the others made with regard to having thousands of iterations instead of just twenty. Why is this a good thing, slowing the algorithm down? It's because most attackers will try to gain access using a dictionary (or rainbow table using often-used passwords, hoping that one of your users was negligent enough to use one of those (I'm guilty, at least Ubuntu told me upon installation). But on the other hand it's inhumane to require your users to remember let's say 30 random characters.

That's why we need some form of trade-off between easy to remember passwords but at the same time making it as hard as possible for attackers to guess them. There are two common practices, salts and slowing the process down by applying lots of iterations of some function instead of a single iteration. PKCS#5 is a good example to look into.

In your case applying MD5 20000 instead of 20 times would slow attackers using a dictionary significantly down, because each of their input passwords would have to go through the ordinary procedure of being hashed 20000 times in order to be still useful as an attack. Note that this procedure does not affect brute-forcing as illustrated above.

But why is using a salt still better? Because even if you apply the hash 20000 times, a resourceful attacker could pre-compute a large database of passwords, hashing each of them 20000 times, effectively generating a customized rainbow table specifically targeted at your application. Having done this they could quite easily attack your application or any other application using your scheme. That's why you also need to generate a high cost per password, to make such rainbow tables impractical to use.

If you want to be on the really safe side, use something like PBKDF2 illustrated in PKCS#5.

回复收藏 0 原文

晚风撩人 2024-12-04 01:37:19

散列密码不是加密。这是一个单向过程。

查看 security.stackexchange.com 以及与密码相关的问题。它们非常受欢迎，我们将其放在一起 这篇博文专门帮助个人找到有用的问题和答案。

这个问题专门讨论了连续使用 md5 20 次 - 查看 Thomas Pornin 的回答。他的回答要点：

20 太低，应该是 20000 或更多 - 密码处理仍然太快
没有盐：攻击者可能会以非常低的每个密码成本攻击密码，例如彩虹表 - 可以创建对于任意数量的 md5 周期
由于没有确定的测试可以确定给定的算法是否安全，因此发明自己的密码术通常会导致灾难。不要这样做

回复收藏 0 原文

陌上芳菲 2024-12-04 01:37:19

crypto.SE 上有这样一个问题，但现在不公开。 Paŭlo Ebermann 的答案是：

对于密码哈希，您不应使用普通的加密哈希，
但有一些专门用来保护密码的东西，比如 bcrypt。

有关详细信息，请参阅如何安全存储密码。

重要的一点是密码破解者不必暴力破解
哈希输出空间（SHA-1 为 2¹⁶⁰），但仅
密码空间，要小得多（取决于您的密码
规则 - 并且字典通常会有所帮助）。因此我们不想要快
哈希函数，但是速度很慢。 Bcrypt 和朋友的设计目的是
这个。

类似的问题有以下答案：
问题是“防范密码分析突破：组合多个哈希函数”
Thomas Pornin 的回答：

组合是 SSL/TLS 对 MD5 和 SHA-1 所做的事情，在其
其内部“PRF”的定义（实际上是一个密钥派生
函数）。对于给定的哈希函数，TLS 定义了一个 KDF，其中
依赖于HMAC，而HMAC又依赖于哈希函数。那么KDF就是
调用两次，一次使用 MD5，一次使用 SHA-1，结果为
异或在一起。这个想法是为了抵抗密码分析的破坏
MD5 或 SHA-1。请注意，对两个哈希函数的输出进行异或
依赖于微妙的假设。例如，如果我定义 SHB-256(m) =
SHA-256(m) XOR C，对于固定常数 C，则 SHB-256 为
SHA-256 等良好的哈希函数；但两者的异或总是产生
C，这对于散列目的来说根本不好。因此，
TLS 的建设并没有真正得到权威机构的批准
科学（它只是碰巧没有被打破）。 TLS-1.2 确实
不再使用该组合；它依赖于 KDF，
可配置的哈希函数，通常是 SHA-256（2011 年，这是一种智能算法）
选择）。

正如 @PulpSpy 指出的那样，串联并不是一个好的通用方法
构建哈希函数。这是由 Joux 于 2004 年出版的，然后
Hoch 和 Shamir 在 2006 年推广，大类
涉及迭代和串联的构造。但请注意
细则：这并不是要克服哈希的弱点
功能，但让你的钱物有所值。也就是说，如果你采取
具有 128 位输出的哈希函数和另一个具有 160 位输出的哈希函数，
并将结果连接起来，则碰撞阻力将为零
比两者中最强者还差； Joux 所展示的是它会
也好不了多少。使用 128+160 = 288 位输出，您
可能会瞄准 2¹⁴⁴ 阻力位，但 Joux 的结果意味着
您不会超过大约 2⁸⁷。

所以问题就变成了：有没有一种方法，如果可能的话，高效
方式，组合两个哈希函数，结果如下
抗碰撞能力是两者中最强的，但不会产生
串联的输出放大？ 2006 年，Boneh 和
Boyen 发表了一个结果，简单地说明了答案
否，仅限于评估每个哈希函数的条件
一次。 编辑： Pietrzak 2007年取消了后一个条件
（即多次调用每个哈希函数没有帮助）。

并通过 PulpSpy：

我确信@Thomas 会给出彻底的答案。在此期间，我只会
指出你的第一个结构的抗碰撞性，
令人惊讶的是，H1(m)||H2(M) 并不比 H1(M) 好多少。看
本文第 4 节：

http://web. cecs.pdx.edu/~teshrim/spring06/papers/general-attacks/multi-joux.pdf

There is such a question on crypto.SE but it is NOT public now. The answer by Paŭlo Ebermann is:

For password-hashing, you should not use a normal cryptographic hash,
but something made specially to protect passwords, like bcrypt.

See How to safely store a password for details.

The important point is that password crackers don't have to bruteforce
the hash output space (2¹⁶⁰ for SHA-1), but only the
password space, which is much much smaller (depending on your password
rules - and often dictionaries help). Thus we don't want a fast
hash function, but a slow one. Bcrypt and friends are designed for
this.

And similar question has these answers:
The question is "Guarding against cryptanalytic breakthroughs: combining multiple hash functions"
Answer by Thomas Pornin:

Combining is what SSL/TLS does with MD5 and SHA-1, in its
definition of its internal "PRF" (which is actually a Key Derivation
Function). For a given hash function, TLS defines a KDF which
relies on HMAC which relies on the hash function. Then the KDF is
invoked twice, once with MD5 and once with SHA-1, and the results are
XORed together. The idea was to resist cryptanalytic breaks in either
MD5 or SHA-1. Note that XORing the outputs of two hash functions
relies on subtle assumptions. For instance, if I define SHB-256(m) =
SHA-256(m) XOR C, for a fixed constant C, then SHB-256 is as
good a hash function as SHA-256; but the XOR of both always yields
C, which is not good at all for hashing purposes. Hence, the
construction in TLS in not really sanctioned by the authority of
science (it just happens not to have been broken). TLS-1.2 does
not use that combination anymore; it relies on the KDF with a single,
configurable hash function, often SHA-256 (which is, in 2011, a smart
choice).

As @PulpSpy points out, concatenation is not a good generic way of
building hash functions. This was published by Joux in 2004 and then
generalized by Hoch and Shamir in 2006, for a large class of
construction involving iterations and concatenations. But mind the
fine print: this is not really about surviving weaknesses in hash
functions, but about getting your money worth. Namely, if you take a
hash function with a 128-bit output and another with a 160-bit output,
and concatenate the results, then collision resistance will be no
worse than the strongest of the two; what Joux showed is that it will
not be much better either. With 128+160 = 288 bits of output, you
could aim at 2¹⁴⁴ resistance, but Joux's result implies
that you will not go beyond about 2⁸⁷.

So the question becomes: is there a way, if possible an efficient
way, to combine two hash functions such that the result is as
collision-resistant as the strongest of the two, but without incurring
the output enlargement of concatenation ? In 2006, Boneh and
Boyen have published a result which simply states that the answer
is no, subject to the condition of evaluating each hash function only
once. Edit: Pietrzak lifted the latter condition in 2007
(i.e. invoking each hash function several times does not help).

And by PulpSpy:

I'm sure @Thomas will give a thorough answer. In the interm, I'll just
point out that the collision resistance of your first construction,
H1(m)||H2(M) is surprisingly not that much better than just H1(M). See
section 4 of this paper:

http://web.cecs.pdx.edu/~teshrim/spring06/papers/general-attacks/multi-joux.pdf