Oh fuck and boy Jesus, how on earth is this still a thing 😦

MD fucking 5 is not a fucking “secure” crypto algorithm.

This site has 14 million breached accounts with fucking MD5 hashes.

I think I’ve had to much internet for today.

I have php classes in school and my teacher uses md5 because "its easier" even tho i have introduced him to bcrypt

because being hashed by md5() makes your password looks cooler than admin123.. 🙈

kinda disgusting how they omit the fact that md5 is not suitable for password hashing
"it's just one way hashing, like every other method"

okay i know that md5 shouldnt be used anylonger... but can one explain me why exactly?
is the algorithm itself unsecure? or because of all these "decryption databases"? I dont have to deal with crypto things... im just curious. please dont beat me up.

@ynnk MD5 is so weak that its basically at the point of being plaintext-readable with an average PC and a suitable MD5-Cracking software. Furthermore, it's utterly broken. Hashing should always result in unique text, however, there is an attack for MD5 that generates a second input with the same hash from another input (collision attack).

Hope this helps a bit.. never ever use MD5, or for that matter, not even SHA unless bigger or equal than SHA-256.

I do have to point out not all their passwords are md5. 500px had been around for a while and apparently the old passwords were still md5 but more rece t ones were bcrypt.

I got a HIBP notif today...

@ynnk just search md5 decrypt online.. if your database breaches with md5 hashes, its the same as plain text..

500px isn't that the fake flickr knock off?

@epse the fact they they allow for MD5 after changing over to Bcrypt doesn’t make it any better, if you change , you change all, now their login process has two checks.

@ynnk MD5 is a simple mans hashing.
It was widely used as it took no time to implement. However as it became found to be very simple to dictionary attack and have multiple strings return the same hash the industry moved away from it for the right reasons.
The same goes for SHA1 as it’s been proven to have collisions as well.

@karma possibly, I never actually used flikr 🤔

@C0D4 I think I had a quick look, only to run away quickly in the early days

@C0D4 how would you do that? You can't change the hash of something you don't know. Except blocking every user and sending mails to reset passwords.

@pain that is exactly what you do, you warn users to re enter their password because the security is getting stronger, and you set a period in which people will still be able to log in with their old password.

Afterwards, you make it prohibitive.

I don't see any other way.

@pain you do a full user password change, and then send out emails to tell users they’ll need to change their passwords in order to continue using the service.

It’s not hard.

@C0D4 What happens to the people who don't follow the link. Will their account be disabled if they don't do it after a few days?

Point is, yes it is that hard. Because most times business won't allow accounts to be disabled. Those people cought come back one day.

@ynnk I think I can expand on your question a bit further.

You asked if encryption dbs are the reason why MD5 is unsafe. I think not, since there are dbs for SHA512 too (a currently safe method).

One-way hashing algorithms are considered 'safe' if it is computationally impossible to find collisions, or finding an input string that results in a given hash.
A collision happens when two different input strings hashed on the same method, return the same result, or more appropriately called, digest.
https://en.wikipedia.org/wiki/...

Here's an MD5 collision shown graphically https://stackoverflow.com/a/933527/...

MD5 has a digest size of 128 bits, which is rather small for our current state of the art technology.
SHA512 OTOH, has a digest size of 512 bits, therefore it has a lot more combinations to distribute values evenly so as to make harder finding collisions, or an input string that results in a given hash.

One more thing about the encryption dbs you mentioned.

They probably store values when using unsalted hashing methods (because it'd be computationally impossible to have a db for every salt of a hash method).

This means that one way hashing methods for sensitive data should always use salts (and never expose it ofc).
This way you protect yourself from these encryption dbs.
But with access to this salt, you could build an encryption db of your own.

Most frameworks take care of using salts for you, though.

@JustThat hehe