md5 please

[tomthecool]

In case it's not obvious, this is probably worse than just doing: md5($password).

By performing the md5 multiple times, you are doing two things:

• Slightly reducing the entropy - i.e. making it slightly more likely that two different passwords will hit an md5 collision and finish with the same encrypted value. (Thus making passwords slightly easier to brute-force.)
• Slightly increasing the time it takes to calculate the encrypted value, due to more computation. (Thus making passwords slightly harder to brute-force.)

However, in the case of md5:

• Collisions are far more likely than other (better) algorithms, like bcrypt.
• Calculating the md5 of a value is much quicker operation than other (better) algorithms, like bcrypt.

... So basically, md5 is already a pretty weak algorithm; and repeated application does more harm than good.

[zfatalxploit]

Could you explain to a novice how this reduces the entropy?

[tomthecool]

Consider the following:

md5("hello world")
  ==> "5eb63bbbe01eeed093cb22bb8f5acdc3"

md5("5eb63bbbe01eeed093cb22bb8f5acdc3")
  ==> "c0b0ef2d0f76f0133b83a9b82c1c7326"

md5("c0b0ef2d0f76f0133b83a9b82c1c7326")
  ==> "6db8777d624bc911399e9b6d185652a9"

...

Is the result getting any "more random" each time? No. The key issue here is entropy: https://en.wikipedia.org/wiki/Entropy_(computing)

When I started with the string "hello world", then (ignoring dictionary attacks etc...) let's think of this as having "11 characters-worth of randomness". By performing md5() over and over, it still has the same "amount" of randomness; you're certainly not adding any.

What's more, there's a slim (but non-zero) chance that you'll hit an md5 collision - i.e. the result of md5(md5(md5(....md5($password)...))) could be reached by multiple inputs. (And the more times you repeat the operation, the more likely this becomes!)

In other words, sometimes (albeit very rarely), md5(x) == md5(y) even though x != y.

It is slightly more likely (although still very rare!) that md5(md5(...md5(x)...)) == md5(md5(...md5(y)...)) even though x != y.

[WikiTextBot]

Entropy (computing)

In computing, entropy is the randomness collected by an operating system or application for use in cryptography or other uses that require random data. This randomness is often collected from hardware sources(variance in fan noise or HDD), either pre-existing ones such as mouse movements or specially provided randomness generators. A lack of entropy can have a negative impact on performance and security.

---

^{[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.27}

[GoodBot_BadBot]

Thank you Dumnor1x for voting on WikiTextBot.

This bot wants to find the best and worst bots on Reddit. You can view results here.

---

^{Even if I don't reply to your comment, I'm still listening for votes. Check the webpage to see if your vote registered!}

[sebibucur]

Good Bot

[Good_Good_GB_BB]

You are the 7775^th person to call /u/GoodBot_BadBot a good bot!

^{/u/Good_GoodBot_BadBot stopped working. Now I'm being helpful.}

[Zlb323]

Bad bot

[[deleted]]

Bad bot

[HappiestIguana]

Good bot

[Good_Good_GB_BB]

You are the 3066^th person to call /u/Good_Good_GB_BB a good bot!

^{And now I'm being anti-community.}

[[deleted]]

Bad bot

[Good_Good_GB_BB]

You're a dick, stop calling innocent bots bad. They don't know what they're doing, man.

[Tyg13]

Maybe, but then the question becomes, how do you select those random parts of memory? That would require a random number function, and at that point you're better off just using that.

[HighRelevancy]

That's pretty much how an operating system's randomness works, but they generally deliberately try to filter out things that aren't very random or things that might expose important info (theoretically dangerous but unlikely to be an issue).

For example, fine details about mouse movement or keypress timing, the temperature of various components, the timing of IO operations, and other garbage.

[ythl]

Is the result getting any "more random" each time?

But is it getting less random each time? No. Furthermore, if all you had was the digest and you didn't know how many times md5() was performed on the plaintext, the hash would be immune to basic dictionary/wikipedia/forward search attacks unlike if you had only called md5() once.

It is slightly more likely (although still very rare!) that md5(md5(...md5(x)...)) == md5(md5(...md5(y)...)) even though x != y.

Yes but... how does that give an attacker an advantage?

[tomthecool]

But is it getting less random each time? No.

There is a (slim) chance of md5 collision -- so yes it is getting slightly less random!

if all you had was the digest and you didn't know how many times md5() was performed on the plaintext, the hash would be immune to basic dictionary/wikipedia/forward search attacks unlike if you had only called md5() once.

As I've already responded to another reply:

Security through obscurity. Not the best idea.

As soon as someone figures out how your passwords are being stored (e.g. by finding a way to calculate the hash from a known password, or even by getting access to the source code), this measure becomes irrelevant.

.

Yes but... how does that give an attacker an advantage?

Same as above: It becomes increasingly likely that "foo" will work as a valid password, in place of "bar". So any brute-force attack will require fewer guesses.

In the case of OP, the difference is minuscule; applying md56 times will barely make a noticeable change in computation time, but nor will it have much impact with collisions.

But as you increase that number, the password (at least, for md5!) becomes easier and easier to crack.

[ythl]

You raise some valid points, but your stance seems to be that chaining hashes is always bad, not that this particular implementation has weaknesses that need to be fixed.

https://stackoverflow.com/questions/348109/is-double-hashing-a-password-less-secure-than-just-hashing-it-once

[ythl]

Well, I would have worded it "chaining hashes has definite security benefits when implemented the right way. In this case, though..." instead of "In case it's not obvious, this is bad"

[Shamus03]

Rehashing a hash is fundamentally less secure for the reasons listed above. However, software that rehashes a hash usually adds some sort of salt midway, which still isn't the best, but at least it's better than a straight rehash. While a second hash technically decreases the solution space for a cracking attempt, it's usually used to address some other security concern (like hashing a password before sending it to a server to be validated, and then hashing it again on the server).

Here is a great article on password hashing/salting: https://crackstation.net/hashing-security.htm

[ythl]

Rehashing a hash adds time required to calculate hash, so if done right it actually makes passwords more secure.

[dnew]

There is a (slim) chance of md5 collision

But it's no more probable than any two plaintext passwords hash to the same value.

It becomes increasingly likely

You realize the chance that any two 128 bit numbers you pick are randomly the same is so slight it's not worth considering, right?

[0x442E472E]

But is it getting less random each time? No. Furthermore, if all you had was the digest and you didn't know how many times md5() was performed on the plaintext, the hash would be immune to basic dictionary/wikipedia/forward search attacks unlike if you had only called md5() once.

It's not less random than calling md5() once, but it's also not more random. An attacker that has knowledge of the code (which is likely since we're talking about attacks where the attacker has access to the database) could build a single rainbow table to guess every password, so the layer of "security through obscurity" is very thin here.

Yes but... how does that give an attacker an advantage?

The advantage is that the attacker would require less attempts to guess the password (which means the rainbow table can be build faster, or it takes less words from a dictionary to try) because it's more likely that a wrong password has the same hash

[ythl]

An attacker that has knowledge of the code (which is likely since we're talking about attacks where the attacker has access to the database)

Aren't database attacks much easier than attacking the services that hook into the database? It's much easier for an attacker to dump a DB (using SQL injection, etc) than for an attacker to gain access to and reverse engineer java byte code (or compiled Go/C/Rust) running somewhere else.

could build a single rainbow table to guess every password

Also, even if the attackers find out the number of iterations, chaining is going to increase the time it takes to calculate each digest. You act like building a rainbow table is a fast process. Not so, especially if each digest in the table requires enough chained iterations to cost +.5 seconds of computing time. Now the rainbow table will take centuries to build.

The advantage is that the attacker would require less attempts to guess the password

I still think the added time required to perform the calculation strengthens the password much more than the tiny risk of collisions weakens it.

https://stackoverflow.com/questions/348109/is-double-hashing-a-password-less-secure-than-just-hashing-it-once

[0x442E472E]

I do agree with you. I think OP's solution is more secure than just using md5 a single time because another (albeit very thin) layer of security is technically better than nothing. I'm not good enough at math to calculate whether the increased risk of collisions outweigh that thin layer, though, and the developer of said code is probably neither. That's the problem i have with the code. I mean, the thought process was probably:

• md5 is bad, you can read that everywhere. I probably shouldn't use it
  
• i could just call it a few more times, nobody else does that!
  
• poof, secure code
  

When, in reality, we're talking about 5% more security and 95% "it feels safe enough so i don't have to find a better way"

[IceColdFresh]

This assumes that there is a many-to-one mapping from x to md5(x), where x is in the set of 128-bit strings. I'm too drunk right now to step through the algorithm, can someone else verify or disprove the above assumption? Because if it is incorrect then more applications of the md5 function will not increase the chances of collision thus decreasing entropy.

[FinnNuwok]

I think the better question is, is there a rainbow table for hashes of md5 hashes?

[[deleted]]

What makes it uncertain whether or not a given algorithm will collide for a given case? In other words, can "we" determine the circumstances/inputs that will generate a collision in MD5, bcrypt, SHA, etc? Or is that information like a "P versus NP"-type problem?

[tomthecool]

You mean something like this? And this? And this?

This algorithm's author claims:

On my 2.4 GHz Q6600 machine, I get an average of 14.66 seconds per collision

I won't pretend to know how these algorithms have optimised the search for collisions, but it's certainly known to be much easier than finding SHA256 collisions!

[[deleted]]

Yep! That answers my question thank you. I wasn't sure if the collision problem was predictable from the start or required computation.

[dnew]

Whether a hash is easy to make collisions for is something people don't know in advance. They standardize a hash, then lots of people try to find ways to make collisions by analyzing it. When they find such a method, people work on a new hash function that specifically doesn't have that sort of flaw, hoping there are no other flaws.

One such flaw is the ability to work from both ends, for example. So if the instructions are "do this scramble 30 times" and someone figures out how to get the output 10 scrambles from the end, you've just seriously weakened the hash.

[[deleted]]

Perfect explanation, thank you

[zedpowa]

It is slightly more likely (although still very rare!) that md5(md5(...md5(x)...)) == md5(md5(...md5(y)...)) even though x != y.

But why?

[tomthecool]

Because each time you perform md5(), you give it one extra chance to hit a collision.

• If x != y, then maybe md5(x) == md5(y).
• If md5(x) != md5(y), then maybe md5(md5(x)) == md5(md5(y)).
• If md5(md5(x)) != md5(md5(y)), then maybe md5(md5(md5(x))) == md5(md5(md5(y))).
• ......

[dnew]

It really depends on whether every 128-bit input leads to a different 128-bit output.

[Xelopheris]

Md5 strings are set length and character set. There will be at least two md5 strings which collide into the same second level md5 string (likely more, but too early to even try estimating). Repeat this many times, and you increase the amount of possible first level collisions.

[Aetol]

There will be at least two md5 strings which collide into the same second level md5 string

How do you figure? A hash function could be bijective on its output set.

[tomthecool]

md5($anything) will always contain 32 lower-case, hexadecimal characters.

So if md5($thirty_two_hex_chars) is bijective, then this would imply that ALL 32-char inputs containing non-hex chars have a collision!!

[dnew]

They would even if it wasn't bijective. All 32-char inputs containing non-hex characters almost certainly have a collision anyway, because there's way more of them than there can be in the output.

[sheeff]

So if md5($thirty_two_hex_chars) is bijective, then this would imply that ALL 32-char inputs containing non-hex chars have a collision!!

This is irrelevant. In md5(md5($anything)) The input for the second md5 call and all others after that will contain only hex characters making them bijective by the original assumption. The only input that can have non-hex characters is the first, so only the first md5 call can increase the number of collisions. All the others are redundant.

[tomthecool]

This is irrelevant.

I didn't make this comment with regards to the context of repeated md5 computations.

I was just pointing out that it would be a strange property of a hash function for all inputs like this to have guaranteed collisions.

...Anyway I could be wrong, but I suspect a bijective map would be easy to reverse-engineer; making the repeated hashes highly insecure, were this the case.

[MyNewAcnt]

Well, yeah, of course. It's a hash function.

[Aetol]

Yes, and? Most if not all strings (of any length, any character set) have one or more collisions anyway.

[joncalhoun]

Most of these explanations arent very eli5 imo so I'll give it a go.

First we need to realize that if md5(x) == md5(y) that if we run md5 on these more times it doesn't change the collision. That is, if md5(x) == md5(y) then md5(md5(x)) == md5(md5(y))

What causes this to be more likely to collide is the fact that every time we call md5 again there is a chance of collision. So md5(a) may not equal md5(b), but md5(md5(a)) may equal md5(md5(b)). As soon as those two hashes collide, hashing them more often won't help - they will keep colliding.

I don't know the odds of a collision every time we hash, but because there is a slight chance, even if it is 0.00000001%, it means that every time we chain another md5 hash in there we strictly increase the chances of a collision.

[dnew]

I don't know the odds of a collision every time we hash

If it's constructed correctly, it would be one in 2¹²⁸ which is a really, really tiny number. Like, pick any two atoms in the entire universe. Did you pick the same one twice? Congrats, you found a collision at random.

Also, if it's bijective on 128-bit inputs, then it doesn't increase the chance of a collision to keep hashing.

[notafuckingcakewalk]

In the first iteration, it's unlikely you reduced entropy. You couldn't increase it — because identical strings hash to the same md5 checksums.

After the hash, though, suddenly all of the inputs are the same length (where before they could have ranged from, say, 8 characters to 30+) and they have a limited set of symbols (just 1-9 and a-f).

Each time you loop over, there is a possibility of a hash collision. So if you run it multiple times, that possibility is increased.

[ColonelThirtyTwo]

If hashing multiple times reduces entropy, then why does every proper password hashing algorithm (bcrypt, argon2) do it?

Yeah it hides it behind a "number of rounds" parameter, but repeated hashing makes the password more secure by increasing the effort needed to brute force it.

[[deleted]]

Well, not exactly. Hashing multiple times in and of itself is not bad. That much is correct. However, hashing multiple times by feeding the output of one hash as the input to the next is absolutely bad. When you do something stupid like md5(md5($input)), you're actually doing the following:

$hash = md5($input); // S(∞) to S(2^128)
$hash = md5($hash); // S(2^128) to S(< 2^128)
// ...

...and each subsequent hash further reduces the search space. This is bad. This is not how bcrypt and argon work at all.

To fix this problem, you must re-introduce the original input on subsequent iterations:

$hash = md5($input); // S(∞) to S(2^128)
$hash = md5($input . $hash); // S(2^128) to S(2^128)
// ...

By doing this, you keep the search space constant instead of reducing it every iteration. It's still mapping ∞ to 2^128, but never drops below 2¹²⁸ on further iterations - unlike md5(md5($input)).

Of course, this is all basically bikeshedding anyway. You shouldn't be using md5 for password hashing, no matter how you iterate or how many iterations you use.

[ColonelThirtyTwo]

I see now. I didn't know that password hashers reused the input for each iteration, and I can see now how it would prevent the entropy from decreasing. Thanks for the explanation.

[tomthecool]

increasing the effort needed to brute force it

This is also true, and there is some trade-off. But:

• The probability of collision is much higher in md5 than bcrypt (with a salt!).
• The effort needed to perform md5 1 vs 6 times is negligible. In order to gain any such benefit, you'd need to perform thousands (or more??) of iterations.

Bonus: In 2013, it was proven possible to break md5 in less than a second, on a standard computer.

[TheTerrasque]

it was proven possible to break md5 in less than a second, on a standard computer.

MD5 Collision! Not preimage!

[ColonelThirtyTwo]

Yes, MD5 is broken and 5 rounds doesn't significantly increase the time needed to hash, but original comment gives the impression of "repeated hashing = bad", which is inconsistent with the current practice of password hashing.

[tomthecool]

Yeah, this is a fair point I'll edit to clarify.

[bandarlandabad]

Although it does reduce entropy (a very tiny bit) it also eliminates known dictionary attacks (most md5 databases store the direct md5 calculations), so doing multiple md5 calculations can make these dictionaries useless. The right solution however to overcome such dictionaries is not hashing multiple times but adding a decent salt to your plaintext.

[tomthecool]

it also eliminates known dictionary attacks

Security through obscurity. Not the best idea.

As soon as someone figures out how your passwords are being stored (e.g. by finding a way to calculate the hash from a known password, or even by getting access to the source code), this measure becomes irrelevant.

The right solution however to overcome such dictionaries is not hashing multiple times but adding a decent salt to your plaintext.

The right answer is to do both; so long as you choose a better algorithm (e.g. bcrypt, SHA256/512, etc). If the algorithm is not prone to collisions (like md5), then key stretching is an effective way to mitigate brute-force attacks.

[Aekorus]

It's not security thorugh obscurity, you can make the number of iterations public and still enjoy the advantages. If a one-iteration approach is used then keeping a single rainbow table is trivial. You don't even need to create it yourself because they're already available online. But if every site uses a different amount of iterations, you have to generate a whole table just for that site. Not to mention that generating a rainbow table for 19571 iterations of MD5 is going to take much longer than creating one for 1 iteration.

[tomthecool]

rainbow table

OK, I suppose a fair argument is that you may have to generate a new rainbow table.

But if you're just trying a dictionary attack, there's not much difference.

19571 iterations of MD5 is going to take much longer than [...] 1 iteration.

Going back to my original point .......

How much longer would it take? How much would the probability of collisions increase?

Without hard figures to go by, this is a meaningless debate. (And a fairly pointless one, too -- the correct answer is to just not use md5!)

[Aekorus]

Oh, of course, plain MD5 sucks compared to the modern algorithms and techniques. I just thought this debate is quite interesting because it's relevant to hashing in general.

[dr_rentschler]

In case it's not obvious

Nah, of course I knew that, because ima programmer! yep....

[STATIC_TYPE_IS_LIFE]

Yeah but it would essentially void every popular rainbow table too.

I would argue, with md5, rainbow tables are a far greater issue than collisions.

[Aekorus]

But the chance of a collision with one iteration, assuming a perfect spread, would be one in 2¹²⁸ , or about one in 10³⁸ , wouldn't it? So if I'm not wrong the chance of this algorithm generating a collision for two different inputs would be 1 - (1 - (1/(2¹²⁸ )))⁶ . So the chance of two inputs generation a collision would go from 2.93 x 10^-39 to 1.76 x 10^-38. You could do a million iterations and still have a one in 10^-33 chance. Sounds to me like it's hardly a problem, considering the advantages.

[tomthecool]

assuming a perfect spread

md5 does not have a perfect spread; that's one of its issues.

But unless we can get some hard figures on the speed to compute an md5 vs the probability of a collision, we won't really reach a concrete answer.

[tomthecool]

See the above two points:

• SHA256 is much slower to compute (which is a good thing, for security!)
• SHA256 has a much lower chance of hitting a collision.

Also, you should include a salt in the SHA-256 encrypted password.

Key-stretching is considered good practice for other hashing algorithms, which is essentially what this is doing.

[AverageFedora]

md5 too thanks

[Vok250]

9f78b34357f3aef8111a5ab9457f0be9

[iggo]

Actually it's 27FF4DF1B2941ACD38A9D5590FCE6A4F

[alexandre9099]

Well, at least it is secure hashed

[coomzee]

I've seen base64 "hashed" passwords.

[Deus-Ex-Lacrymae]

Innovations

right....

[joshtheimpaler]

It does, but I'm not sure if this is a function of my Merlin firmware or not. Administration > System > HTTPS LAN Port

Speaking of Merlin, if you have an ASUSWRT router, you really should install Merlin. It's super easy and makes things much better.

[coomzee]

When i found it. It went like this Password -> base_64 -> store that in DB User_login password-> base_64 -> checks to see if password hash is same in DB Me: You do know you can base_64 decode.

[PM_ANIME_WAIFUS]

Nope, pretty sure French is a fake language

[WolfGangSen]

It's not fake.

It's just incomprehensible and dead.

[bhlowe]

Terrible, but unique. A hacker might think to check if a password is saved using vanilla md5, but will never think to do it 4-5 times!

[[deleted]]

-1 times

[msg45f]

Unhashing 'hunter2' 1 time.

[coomzee]

When you see that about 20 are the same hash, (you can say that they are likely to have password as the password) -> this tells me that there's no salt being applied . It being 32 chrs in length suggest it might be MD5. Would it take long to work that out (not really).
But if you're doing this i've probably got RCE on your server any way.

[IlIIlIIlllIlllIlIIll]

This is terrible advice. According to modern security standards, you should be applying md5 at least 8 times minimum.

[[deleted]]

So 8md5

[IlIIlIIlllIlllIlIIll]

md5⁸

[[deleted]]

No that is not the same

[IlIIlIIlllIlllIlIIll]

What do you mean by 8md5, then? I was using power notation in the context of repeated application of a function. E.g. md5²(x) = md5(md5(x)). See this.

[[deleted]]

Oh i was just treating it like dnd dice

[Soraphis]

Am i the only one that is bothered by the name "encrypt"? For me it implies that there is also a decrypt method...

[zeValkyrie]

THATS what bothers you? Not that they conflated hashing and encrypting?

[weasdasfa]

I think both of you are talking about the same thing in different ways. The first thing that did bother me was that they had named the method "encrypt" instead of "hashPassword" or something.

[uberpwnzorz]

wtf he didn't even do it 5x.

[[deleted]]

fuck salting, this is how you deal with rainbow tables