Why WordPress should abandon Old PHP Password encryption algorithms.

As a hardening issue and can be discussed publicly.

In fact, it has been discussed publicly for years:

https://core.trac.wordpress.org/ticket/50027

WordPress uses the Portable PHP Password Hashing Framework, which uses the bcrypt hashing algorithm and more so the password encryption includes php functions calling the password_hash script with either the PASSWORD_BCRYPT or PASSWORD_ARGON2I or PASSWORD_DEFAULT with the most common being password_default as a one way hashing algorithm .

However , if an attacker compromises a database and navigates to wordpress passwords, they’re encrypted and he/she cant find the original passwords and meaning he cant login to the wordpress sites whatsoever. But what if he worked this backwards to front? What if he managed to use his own password to access the sites and in password publications or leaks, he will publish real usernames with passwords that he wants (mostly he will do randoms) and the combinations work in wordpress login thus “somehow” bypassing the wordpress encryption algorithm which uses php.

Lets do a fast easy reproduce to explain:

1. Create a website/subdomain

• e.g: example.com Now do a wordpress installation in the root folder of example.com or the subdomain.
• Automatically a new user (administrator is created) and this time with a username that’s not so common and quite complex.
• Lets say: admin_vzyog96 which my wordpress installation assigned me. Now, the new user also has a password: I was assigned password: pePi7TEmp3o$ez8o and its encrypted version in the database was: $P$B.f9pHoT7fKNuCadbF8x3pGoe60tis1

Now go to database and where users are listed: One user for new installs , as an attacker with access to database and I must maintain access for constant data extraction or else maybe do data breaches or extortion etc. But how? Since the password stored is one way hashed?

• Working that out by reverse.

1. Generate a random password using a simple PHP script below:

<?php

// Get the new attacker password
$password = 'mypassword';

// Generate the hash
 
$hash = password_hash($password, PASSWORD_DEFAULT);

// Display hashed password to use
echo $hash;

?>

The password I got is: $2y$10$k2JDEx4b8aI6rmFM942Inuy9./CazL1Dr3Pu9Qcl90W3zaJcq4q/e 5. Now copy that and go to database and edit the password directly(most databases,sql, allow for editing by double clicking in the password value field). Paste the new password: Remember the original is: mypassword

1. Now go to the wordpress admin login url of your site: ie. example.com/wp-admin Use the username assigned from the start: admin_vzyog96 and the new password you generated $2y$10$k2JDEx4b8aI6rmFM942Inuy9./CazL1Dr3Pu9Qcl90W3zaJcq4q/e . The combination logs you in. As the attacker I can now own the username : admin_vzyog96 and password: $2y$10$k2JDEx4b8aI6rmFM942Inuy9./CazL1Dr3Pu9Qcl90W3zaJcq4q/e and use the data for anything I wish and in a breach, I now have the full login combo set.

How is that an issue??

Initially as the attacker I could not login to WordPress because I did not have the original password I also could not do anything with just a username and one-way hashed password but now I have both and they are working.

That’s easy ATO.

Someone can also not that the only way the victim(given that wordpress basically needs drag and drop knowledge and a little creativity) can know the database was compromised is using auto login with WordPress Toolkit and that comes in mostly cpanel and not with all WHM service providers . Not all wordpress sites ever handle logins with the toolkit as well.

I realized MD5 hashes can also replace WordPress hashed passwords and still authenticate as the wp_includes/pluggable.php will still handle the MD5 and encrypt then compare to database without any errors meaning no special key/security in place from the default PHP Password Hashing Framework.

How does this not prove as a php feature??

Try crypt, a hashing algorith that uses php and a key: The script:

<?php

// Get the password from the user
$password = 'mypassword';
$key = "khgfewtyui89283764treyduhjzksjahdgfret6738q29iojashdgftye7w8q9ioakjshdgfyrew8uioqwuehgyrfyewuiqouehgdfeyw78q9iowue8y7648392qiowushdgfshajk";

// Generate the hash
$hash = crypt($password, $key);

// Print the hash to the screen
echo $hash;
?>

The logins do not work and no matter how much you replicate the passwords, the hashing doesn’t break and the attacker only has a hashed password and username which are useless. Why is that? Because the wordpress installation does not have the crypt keys now and reversing roles, if the wordpress installation had the keys and the attacker did not… He would never be able to generate the password hash.

From that I believe you understand the logic behind the Inadequate Encryption of the passwords for all WordPress versions to date.

Recommendation

Perhaps WordPress DevOps team should consider crypt or a better password hashing algorithm than crypt as it is more safer than the current used in WordPress versions for password hashing as MD5 replicates the same and as for the key there can be its generation by the md5 or any other encryption algorithm to assign the keys differently per installations

I believe that would have solved the issue considering in the new scenario, am attacker can not by any means replicate a hash or add any hash to database as his hashing will not bypass the crypt keys in password hashing before comparison with the hash string in database. The crypt key can’t by any means be bypassed and as I mentioned consider a randomized already encrypted keys for all new installations for wordpress such that no 2 installations ever share the same keys or by any means no one replicates the randomized assigning of the security keys.

I tried this on WordPress 6.1.1 meaning to date and back all wordpress versions are affected by this issue

What can that prove as having security Impacts?

The Inadequate Encryption Strength for the passwords leads to(but not limited to):

1. Increasing attacks surface as an attacker can randomly maintain access in the victims database as long as he wants.
2. All wordpress installations are vulnerable to Takeover with all versions vulnerable as the hashing and method i called “back to front” is reproducible in all versions of wordpress and again bypasses the encryption put in place to store “secure” passwords in database. That is basically to keep of attackers after breaches or modifying the credentials after access but now not any more….
3. Attackers can now publish wordpress leaked databases with their own password combinations having that they can change the passwords to any values and the new values authenticate correctly.

• If passwords are not adequately encrypted, personal information such as names, addresses, and financial information may be at risk of being accessed by unauthorized individuals who now can setup any passwords and maintain access for as long as they wish. Identity theft can also arise where where someone’s personal information is used to commit fraud or other crimes. Loss of confidential information: If passwords are not properly encrypted, it may be possible for unauthorized individuals to access and leak confidential business information, leading to potential financial losses and damage to a company’s reputation

The old php encryption has laid around for too long that attackers have mastered the art of exploiting it and the developers and WordPress community still debate on whether it should change or not or rather have a better encryption algorithm, of-course based on php.

Many ideas lie out there but in general the point is : It is time to evolve the password encryption

Photo by Stephen Phillips - Hostreviews.co.uk on Unsplash