Fun fact: Wordpress uses md5 to hash passwords.

Source?

It does, and it is salted too.

That whole password hashing thing is just mitigation for people not using site-specific passwords in the first place. Also, if you p0wn the wordpress installation, you can record actual user passwords as they come in and Wordpress is widely used, so canned payloads probaly exist on the market. And then it even depends on how md5 is used (it's mostly about the count of iterations) to actually decide whether there really is room for improvement on that aspect of the "security" theater which basically only protects against the narrow exploit spectrum where you get to read the database but can't inject code into the webapp (mostly SQL injection).

Wordpress' toxic plugin market is way more severe a problem, than that the passwords at rest (maybe) aren't hashed properly. Also pretty perverse that now passwords are seen as more worthy of protection than the actual data or service access they ought to secure...

@Lensflare docs:

https://developer.wordpress.org/ref...

It is designed to be overridden by plugins too.

@Oktokolo all personal data in db such as emails names surnames should be cached as well

@topsecret230 hello d28fb44b1baecd58103fa48f8cc4d0e3!

@Oktokolo I agree with most of what you wrote but there are different levels of breaches. So a data breach is not granting the attacker access to the plain text passwords floating trough the app. There is a big difference in persistent and in flight data regarding security.

Hashing credentials is not just a protection against credential reuse. It's also basic protection of the account itself and all the access it grants. This could be credit card information stored in a secured service for example.

Even though the implementation is highly important and from what I can see it's quite ok, MD5 is just to weak. Assuming it's the function @Demolishun provided the docs for.

It's argument for using MD5 is also weak. PHP comes with a good built-in password_hash function since 5.5 (2016). It's possible to use that implementation for new passwords and retain the old one for backward compatibility. It can even be upgraded on successful login. Hope they did something like that, didn't look further into it.

@kiki I mean they can be decrypted on the fly. In case of database breach, that db would be useles then.

@topsecret230 hashing and encryption are two different things.
Passwords can be hashed because all you need from a password is to be able to tell if it is equal to another password. And that can be done with hashes directly.
But for emails, you need the value unhashed to be useful.
Also, hashes are one way functions conceptually. You can not just "decrypt" the original value.

@Lensflare come on, store the key in codebase and problem solved.