Encryption (MD5) several times can improve security?

Question

I saw a guy who encrypted user password several times using MD5 to increase security. I'm not sure if this works, but it doesn’t look very good. Does that make sense?

Answer 1

Suppose the hash function used is an ideal one-way function. Then you can view your output as 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 several times? The output will remain in the same range (2 ^ 128). It looks like you say, "Guess my random number!" Twenty times, each time thinking about a new number - this does not make it more difficult or easier to guess. There is no “more random" than random. This is not a perfect analogy, but I think it helps illustrate the problem.

Given the forced password entry, your scheme does not add any security at all. Worse, the only thing you could “accomplish” is to loosen security by introducing some ability to reuse the hash function. This is unlikely, but at least it guaranteed that you probably won’t win anything.

So why is still not all lost with this approach? This is because others have expressed the view that there are thousands of iterations instead of two dozen. Why is it good, slowing down the algorithm? This is because most cybercriminals will try to gain access using a dictionary (or a rainbow table using frequently used passwords, hoping that one of your users is careless enough to use one of them (I'm to blame, at least Ubuntu told me about installation). But, on the other hand, it is inhumane for your users to remember, say 30 random characters.

That's why we need some form of compromise between easy-to-remember passwords, but at the same time make it so that attackers can guess them. There are two common practices: salt and process slowdown, using many iterations of some function instead of one iteration. PKCS # 5 is a good example to learn.

In your case, using MD5 20,000 instead of 20 times will slow down attackers using the dictionary significantly down, because each of their input passwords will have to go through the usual procedure of withdrawing 20,000 times in order to be useful as an attack. formatting as shown above.

But why is salt use even better? Because even if you use a hash 20,000 times, a resourceful attacker can pre-compute a large database of passwords by hashing each one 20,000 times, effectively creating a custom rainbow table specifically designed for your application. By doing this, they could easily attack your application or any other application using your scheme. To do this, you also need to create a high cost for the password in order to make such rainbow tables inappropriate.

If you want to be safe, use something like PBKDF2 shown in PKCS # 5.

Answer 2

Password hashing is not encryption. This is a one-way process.

Check out security.stackexchange.com and password issues. They are so popular that we put together this blog post to help people find useful questions and answers.

This question specifically discusses the use of md5 20 times in a row - contact Thomas Pornin. Key points in his answer:

• 20 is too small, it should be 20,000 or more - password processing is still too fast
• No salt: an attacker can attack passwords with a very low cost per password, for example. rainbow tables - which can be created for any number of md5 loops
• Since there is no sure test to know if a given algorithm is protected or not, inventing your own cryptography is often a recipe for disaster. Do not do this.

Answer 3

There is such a question on crypto.SE, but it is not publicly available. Answer by Paŭlo Ebermann :

For password hashing, you should not use a normal cryptographic hash, but something has been done specifically to protect passwords such as bcrypt.

For more information, see How to Store Password Safely .

The important point is that password crackers should not use the bruteforce hash output space (2 ¹⁶⁰ for SHA-1), but only a password space that is much smaller (depending on your password, rules - and dictionaries often help). Thus, we do not want a fast hash function, but a slow one. Bcrypt and friends are for it.

And a similar question has the following answers: The question arises: "Protection from cryptanalytic breakthroughs: combining several hash functions" Answer of this question Thomas Pornin :

The combination is that SSL / TLS works with MD5 and SHA-1, in defining its internal "PRF" (in fact, it is the Key Output Function ). For a given hash function, TLS defines a KDF that relies on the HMAC, which relies on the hash function. Then KDF is called twice, once with MD5 and once with SHA-1, and the results are XORed together. The idea was to withstand cryptanalytic gaps in MD5 or SHA-1. Note that XORing the outputs of the two hash functions relies on subtle assumptions. For example, 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 gives C, which is not entirely useful for hashing. Consequently, the construction at TLS is not really authorized by the power of science (it just didn't break). TLS-1.2 no longer use this combination; he relies on KDF with one, a custom hash function, often SHA-256 (which is a smart choice in 2011).

As @PulpSpy points out, concatenation is not a good general way to hash a building function. This was published by Joux in 2004, and then generalized by Hoch and Shamir in 2006 , for a large class involving iterations and concatenations. But remember the small print: in fact, we are not talking about the remaining weaknesses of the hash of the function, but also about how to get money. Namely, if you take a hash function with a 128-bit output, and another with a 160-bit output, and concatenate the results, then the collision resistance will not be worse than the strongest of them; that Joe showed that he would not be much better. With 128 + 160 = 288 bits of output, you can target ^2,144 resistance but the Joux result implies that you will not go beyond about 2 ⁸⁷ .

So the question is: is there a way that is as effective as possible to combine the two hash functions so that the result is the same as the collision-resistant one, the strongest of the two, but without an increase in concatenation? In 2006, Boneh and Boyen published a result that simply states that there is no answer, with the condition that only each hash function is evaluated once. Edit: Pietrzak raised the last condition in 2007 (i.e. calling each hash function several times does not help).

And PulpSpy :

I am sure @Thomas will give a detailed answer. In the gap, I’m just that the collision resistance of your first construction, H1 (m) || H2 (M) is surprisingly not much better than just H1 (M). See section 4 of this article:

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

Answer 4

no, this is not a good practice, you should use $ salt for your encryption, because the cand password will be cracked using these rainbow tables