For improved security - Rehash user password after so many logins

Governance Community Feedback
1

One of my biggest security-related concerns - was the fact that WordPress does NOT ever update the hashed user passwords. There are several other CMS’s in use which do like: “AirShip”, and I believe Drupal might. This would be as simple as rehashing a user-password after so many times that user’s account is logged in. This could be done during the particular log-in action if a “log-in counter” reached the count that determined when a “refreshing” of the user’s password is due.

Note, this is NOT the same as actually changing a user-password.

IF possible,

An additional administrative setting would allow the administrator to set the rehash timing count to whatever value was deemed appropriate, based on the level of activity of the blog. - Again, this rehashing the user-password would happen when the user is logging in. So very little processor time would be consumed in performing this function.

Being that ClassicPress is targeted to work in PHP 7 and newer,

Then there is no need to use a “portable” password-hashing module with the backwards-compatibility code in it any longer. (Speaking of the “PHPASS” module.) It could be changed to prefer using PHP’s built-in ARGON2ID password-hashing, while still allowing older sites - still using the old PHPASS methods - to continue using the older PHP password-hashing functions.

I am more than willing to help out with the conceptual coding, at least of the new password-hashing module as part of the solution.

But the main important point I wanted to stress on - was that ClassicPress could benefit with a bit more improved security - by periodically rehashing the user-passwords in the database, and that it could be done with very light use of the computing resources.

1 Like
2

Thanks for sharing. :slight_smile:

Do you know where the rehashing information for Drupal and other CMS is located?

My search isn’t going well, I keep finding references to PHP Native password_hash for Drupal | Drupal.org, which replaces PHPass, but I’m unable to look up how it works in other systems. Let me know. :sunglasses:

3

We have discussed moving to bcrypt or Argon for version 2 of ClassicPress, and will no doubt revisit that discussion when we get there.

As for re-hashing, I’m not sure whether this should be part of core or something that’s better left as a plugin. Indeed, you can already get what you’re looking for by using the Salt Shaker plugin.

3 Likes
4

Nice to hear about upgrading which hashing function.

As far as using another plugin for updating the password hashes, I am not really favorable towards that idea because that actually introduces additional problems - like: What if the developer of said plugin no longer wishes to maintain it (as just an example)?

Plus,

How many new users of ClassicPress will even be aware of such a plugin existing, let alone anything about rehashing passwords - if they are not informed of the possibility from the admin screen? - I didn’t even know any such plugin existed, until you just mentioned it.

Such a rehashing function could probably be done in just a few lines of code.

It’s still a valid idea, isn’t it?

5

This is the world of open source. If the developer stopped working on the plugin, someone else could fork it. It’s also easy to change hashes manually.

6

Please explain where this may be done - without actually going into the database itself to do so.

Trust me. I HAVE explored the database many times, and most who have interest - would not even think to tangle with the database by hand to deal with this. Unless you actually know of a much easier way, I and I’m pretty sure many others, are “all ears”.

That does not always happen.

I’ve seen useful plugins eventually die and fade away, because NO ONE picked up their continued development. The WordPress repository is still full of “orphaned projects” (at least, until their admins get around to cleaning them out).

7

Unfortunately,

Some of the more detailed articles seem to have “dropped off the face of the internet”, and a hard-drive crash wiped out all of my home archives before I had chance to back them up. I do know that was one of the security complaints about WordPress: Not “refreshing” the password hashes in the database on occasion.

AirShip CMS seems to not be very active in development over the last several years, plus - it requires Composer in order to install. - Not something I feel the need to go through, just to run an instance of AirShip CMS on my home development system - which was to mainly develop simple themes and plugins for it.

1 Like
8

Hashes aren’t stored in the database. Doing so would render them worthless. They are stored in the wp-config.php file, where you’ll also find instructions on how to change them manually.

1 Like
9

Tim, I think you need to read some stuff. Hashes are stored in the database, so that the actual password is not stored where anyone can see it. Those strings in wp-config.php are the salts that are used when hashing.

I’m not sure I understand the whole point of rehashing a password. I thought that a password is not saved, but the hash is. So when the user tries to log in, the hash of the password they entered is compared to the hash stored in the database. If they match, they are logged in. Otherwise, how would it work? How can you get a different hash for the same password and still have this logic?
What am I missing?

2 Likes
10

The salts are in wp-config
define(‘AUTH_KEY’, ’ etc.

11

Joy, yes, that’s correct, but the mechanism for changing the hash requires that the salts be changed. You can’t change the hash directly. By changing the salts, you can change the hash.

That’s precisely what the Salt Shaker plugin, discussed above, achieves. Since the OP wanted an alternative to that, that’s what I explained (though you’re right I used the word hash when I meant salt).

1 Like
12

Exactly, Mark.

13

Please allow me to “humbly” correct you.

A couple of other commenters here already replied that the wp-config.php contains the “SALTS” which are used to help secure-generate the temporary hashes for things like “cookies”, “nonces”, etc - but are NOT the user-password hashes themselves.

The user-password hashes ARE stored in the designated “WP database” on the “???_users” table, and the specific column is: “user_pass”. - THESE are the user-password hashes I was talking about from the very beginning.

Please explore your own “WP database” and find them at: “???_users” (not “user_meta”) and under column “user_pass”. This is for the WP users, NOT the database user(s).

Sorry to sound thorny about this, but I get frustrated when people do NOT carefully read my often very-detailed posts, before trying to shoot me down! I have used WordPress for a long time myself. There have been plenty of occasions where I have had to go into the database and manually change or correct bad settings from the “database manager” (PHPMyAdmin, for example). - I don’t envy ANYONE who ends up having to do this to fix any problems - or even to clear out old data that fails to be deleted from the database otherwise.

As for regularly changing out the salts in the wp-config.php (especially on a schedule),

I can do that with a “drop-in” bit of code anyway. It’s great that WordPress (and by heritage, ClassicPress) adopted generating their own salts, locally, during initial installation. This was a brilliant move - as it also made local installs on machines without internet access also usable with “the _press’s”.

I’m done arguing now. This issue is apparently going nowhere; Sorry to bring it up.

Thank you all for your patience.

14

To finally answer a few questions about this suggestion (in answers to questions by “timkaye” and “joyously”:

First off,

Allow me to post a link from php.net on the subject of “password-hashing”: PHP: password_hash - Manual

As stated in the on-line documentation page, “password_hash()” generates its own salt, and based on which algorithm is chosen (by selecting it through the “algo” argument), is what determines what the resulting hash will look like.

The “salts” values in the wp-config.php file are only part of that process, but “password_hash()” still produces its own salt, and as of PHP8+ - no user-provided salt will be used any longer in the generation of the password hash.

In other words,

You can iterate the password_hash() function, using the same plain-text password AND chosen algorithm as the arguments, and you will STILL have a different password hash as a result for each and every iteration (or “call”).

Sorry it took so long for me to revisit this topic, but “life” can sometimes keep one very busy with other things.

What’s really nice, is that PHP also has a great function for verifying passwords against a provided hash, regardless which (native PHP) algorithm was used to create the hash. AND - the “password_verify()” function is also compatible with hashes generated by the PHP “crypt()” function.

More info on “password_verify” here: PHP: password_verify - Manual

So this really makes implementing a newer password hashing and verifying module pretty “academic”. It just makes more sense being that there is much more available computing power, these days, available to just about anyone - who wish to try to brute force password hashes.

As far as for changing the salts in the wp-config.php file periodically,

That is still a very good idea anyway, but its main effect is in canceling (IE: shutting off) any logged in sessions which are still “logged in”. That still will not invalidate any of the stored password hashes to the user accounts (which ARE, in fact, stored in the WP database).

Two entirely different animals.