多次加密(MD5)可以提高安全性? [英] Encrypting(MD5) multiple times can improve security?

查看:464
本文介绍了多次加密(MD5)可以提高安全性?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我看到有些人用MD5多次加密用户密码,以提高安全性。我不知道这是否有效,但看起来并不好看。那么,这是否有意义?

解决方案

我们假设你使用的哈希函数将是一个完美的单向函数。然后,您可以查看其输出,如随机oracle,其输出值为值的有限范围(MD5为2 ^ 128)。



现在如果多次应用哈希会怎么样?输出仍将保持在相同的范围内(2 ^ 128)。就像你说猜我的随机数!二十次,每次想到一个新的数字 - 这不会使它更难或更容易猜到。没有任何比随机的更随机。这不是一个完美的比喻,但我认为这有助于说明问题。



考虑到强制使用密码,您的方案根本不添加任何安全性。更糟糕的是,您唯一可以完成的是通过引入一些可能性来利用哈希函数的重复应用来减弱安全性。这是不可能的,但至少保证你肯定不会赢得任何东西。



那么为什么还没有全部失去这种方法?这是因为其他人对于有数千次迭代而不是二十次的观念。为什么这是一件好事,减慢算法呢?这是因为大多数攻击者将尝试使用字典(或彩虹表使用常用密码,希望您的一个用户能够使用其中一个(我有罪,至少Ubuntu在安装时告诉我),但另一方面,要求用户记住让我们说30个随机字符是不人道的。 / p>

这就是为什么我们需要在易于记住的密码之间进行某种形式的权衡,但同时尽可能地使攻击者猜到它们。实践,,并通过应用大量的一些功能的迭代来减缓流程的单一迭代 PKCS#5 是一个很好的例子来研究



在您的情况下应用MD5 20000 inst 20次的攻击将使使用字典的攻击者减慢,因为每个输入密码都必须经过20000次哈希的普通程序,以便作为攻击仍然有用。请注意,此过程不会影响暴力,如上所述。



但是为什么要使用盐更好?因为即使你应用哈希20000次,一个资源丰富的攻击者也可以预先计算一个大型密码数据库,每个密码哈希20000次,从而有效地生成一个专门针对你应用的定制彩虹表。做到这一点,他们可以很容易地攻击您的应用程序或任何其他应用程序使用您的方案这就是为什么你还需要生成一个高密度的成本,使这样的彩虹表不可用。



如果你想要真正安全的一面,如PKCS#5中所示的PBKDF2。


I saw some guy who encrypt users password multiple times with MD5 to improve security. I'm not sure if this works but it doesn't look good. So, does it make sense?

解决方案

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.

这篇关于多次加密(MD5)可以提高安全性?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆