A major update, version 2.4, just two months after 2.3—that’s not bad. It’s less intimidating than the previous one. The changelog is short, and the risk of seeing a 2.4.20 version is very low. Let’s see what this new feature is and why it was added precisely.

SecuPress 2.4

Midas, the Mark XXI of Iron Man’s armor, is specialized in supersonic flight, ultra-fast flight, a bit like the speed of this major release…

3 Fixes & misc.

Only 3 very simple fixes. One to prevent URLs like https://example.com/wp-admin/admin-ajax.php?action=secupress_dcts_timer&timer=1765432988 from appearing in your Google Search Console logs. Usually, these URLs aren’t indexed even on the frontend. WordPress itself adds a variable like ajaxurl via localize_script, but anyway… I removed it, did without, tweaked a few things, and it still works.

The second fix, for Pro users, addresses duplicate malware database update notifications. The message appeared multiple times in the notification—this is now fixed.

Finally, the last fix is ​​that password resets were not possible for certain roles, due to the activation and deactivation of the PasswordLess module and whether the strong passwords module is active.

For details, this is to better inform users that the link to an author’s page will be redirected to the site’s homepage if the “Prohibit account listing” module is active. This is a customer request, so listen!

Also, in the PasswordLess module, if your role is on the list of people who should use 2FA, then the password reset request will be prohibited, since it is unnecessary.

Finally, another customer request: a filter hook secupress.get_wp_directory has been added to our function secupress_get_wp_directory() to override the value to make it more compatible with BedRock (with which we are not specifically compatible).

Let’s get to the serious stuff:

Force a Better Encryption System

We’re talking about the WordPress password encryption algorithm. Even if you (and everyone on your site) uses 2FA, stay with me, because this feature can still prevent hacks. Pay attention.

Forcing the Best Available Password Encryption Method

Why?

Why force a better encryption system? I’ll refer back to what I said in the v2.3 article: “Every time I discover a new type of malware targeting WordPress, I try to find a way to counter it with SecuPress. Sometimes it’s just a malware signature, but sometimes I have to do much more.” This is one of those “much more” cases.

Version 2.3 blocks many ways accounts could be added, preventing these accounts from logging in. But some malware is very clever. If…

The Best Encryption System

But how do we know it’s “better”? We had PHPass before (using Blowfish), and since WordPress 6.8, we have Bcrypt. Bcrypt is already better than PHPass, but it’s starting to age. Remember, Bcrypt has been the default algorithm since PHP 5.5, released in June 2013 (WordPress 6.8 was released in April 2025—that’s 12 years old…). We should have had it in WordPress sooner. Even I should have added it to SecuPress earlier; it was on the TODO list, but priorities, you know.

Is there something better than Bcrypt, and why is it better? Well, it’s a bit like saying “Linux is better than Windows” because viruses are almost non-existent on Linux. If 100% of WordPress sites use Bcrypt, malware will include workarounds for Bcrypt, not PHPass.

PHPass passwords start with $P$, Bcrypt passwords with $2y$, but WordPress adds its prefix, resulting in $WP$2y$.

Can PHP offer something else? Yes! We have ARGON2i and ARGON2id, available in the password_hash() function choices (see the PHP documentation). These start with $argon2i$ and $argon2id$, respectively.

Argon2i is better because it’s not the default choice—that’s already a plus. But in reality, Argon2i is better because it requires more resources to create and verify a password. Remember, high speed is a bad thing, and low memory consumption is too. The algorithm MUST be expensive to prevent attackers from using minimal server resources to crack it via brute force. Also, Argon2i—and especially Argon2id—is designed to resist specific attacks. Okay, less than 1% of WordPress sites truly need it (unless you’re a government or banking institution), but if you can do more, why not?

Quick Overview

I might teach you something… 3 things, 3 security points about WordPress that I find strange.

Duplicated Hash

If you create a WordPress site locally, set the password to “azerty,” take its hash, then go to an online site, access its database, and replace the user_pass of the targeted account with this local hash, you will be able to log in to that account using the password “azerty” without raising any suspicion from WordPress. This is because passwords are not tied to the site where they are created; security keys (or “salt keys”) are not used in the creation or verification of passwords (which makes sense, as changing them would invalidate 100% of connections in a second). Additionally, no salt is provided to these new algorithms—they generate their own for security reasons (we know some of you would just use “foobar,” “0“, or even “time()” to cut corners…).

Obsolete Hash

Even funnier, if you replace the user_pass of an account on the targeted site directly in its database with an MD5 hash, or if you’ve already opted for Bcrypt or even Argon2i, replace it with an old PHPass hash—you’ll still be able to log in, thanks to backward compatibility. Backward compatibility with MD5, which was declared obsolete in 2005, 20 years ago. Who needs security that’s backward compatible for 20 years? No one.

Collided Hash

Here’s another funny one. You probably know that a hash is randomly generated and that the probability of having two identical hashes for two different passwords (or even two identical passwords) is unlikely. Even current quantum computers from Alphabet haven’t managed to find a collision (two identical hashes for two different strings). It’s easy with MD5 since 2004, possible with SHA128 since 2017.

But in WordPress, the user_pass field allows duplicate values. So, I can create a legitimate customer account on a site, get my hash with the correct encryption method, SecuPress validates everything, and I’m good. Now, the attack is simply to copy/paste my hash into the admin’s hash. We’ll have the same hash, but it’s allowed (and useless!). I know their password because it’s mine! As I said, password hashing doesn’t take any site or account seed/salt into account.

You didn’t know all this? Shocked? I always have been. That’s why I decided to add two Pro options to this new feature to counter it.

Bonus Point

For your information, here are some examples of different password hashes. Try to guess them; if you do, tweet them to me @secupress.

• MD5: ab4f63f9ac65152575886860dde480a1
• PHPass: $P$BkTFWd.sWcyDBj23k46IIAe1nm4Axb0
• Bcrypt: $wp$2y$12$VqcTFP4kjCDpUs24F26QsOuXTaEUSYvaIPYMK/0iTqvPWh7gUoKm.
• ARGON2iD : $argon2id$v=19$m=65536,t=4, p=1$6u1KLDET9M+YjLlucPquCQ$pJfcLxQOKxOMaiDV+tqwJLY81Nha3qt55+fAf1ahw2I

You can even see the parameters in plain text. The memory used, and even the random string chosen and used by the algorithm! Yet, even with this information, you can’t reverse-engineer the password—it’s irreversible. All you can do is compare whether the given password produces this hash with these parameters. With Argon2i, it’s expensive and slow, so it’s much better!

Prevent Login with Other Encryption Methods

Once the new method is forced (it can remain the same, but it will be enforced), if a new account (old accounts can still do it once, while they automatically switch to the new encryption method) tries to log in, SecuPress checks if it’s using the required method. If not, it refuses the login, stating that the password is incorrect—which is technically true. The password is correct, but not its encryption method!

Currently, WordPress allows logins even with MD5 passwords, and if necessary (yes, necessary), it re-encrypts the password to update the hash according to the current method. This is now forbidden with SecuPress 2.4.

This prevents ALL old malware that manages to modify or manipulate a manual SQL query to add or modify accounts. The block is simple and effective.

Prevent Password Hashes from Being Reused by Other Accounts

As I said, I can also copy a hash from one account to another. But you might say, “Just swap the hash of the targeted account with mine, so there’s no duplication.“

SecuPress also solves the issue of duplicate hashes in your database by creating a UNIQUE INDEX on the user_pass field in the wp_users table. Performance-wise, disk and memory usage are imperceptible, but the security gain is enormous.

Note that with this option, each SecuPress installation will generate a “master key,” which will be its own random seed and won’t change. However, it will differ from one site to another, making passwords unusable elsewhere.

This isn’t a big issue—a simple “reset password” request will fix it, or just don’t enable this feature on staging/dev environments. Enabling and disabling it doesn’t ensure smooth migration either, because technically, account passwords are modified without the owner’s knowledge, with an additional unknown and humanly unreadable string. One login is required to change it, in either direction.

That’s It?!

Yes, that’s all for 2.4. Version 2.5 is already in the starting blocks with a geolocation feature during login, preventing connections from unusual locations. You can adjust the granularity from fixed IP to city, region, or country. Here’s a sneak peek:

See you in November for the 2.5 beta and a release before Christmas 😉