WordPress Password Security Follow-up

Originally published at: https://roots.io/wordpress-password-security-follow-up/
I wrote a blog post about on improving password security in WordPress and the Roots team created a plugin called wp-password-bcrypt to improve it a few weeks ago. Late Friday night, a few people (including myself) got into a Twitter argument about these security issues. Andrew Nacin, a Lead Developer of WordPress, ended up tweeting…

8 Likes
If you're on PHP >= 5.5 then use our bcrypt plugin... You'll improve your site's security.

Still wrong.

This only “improves” the security of your user’s passwords in the event that your site has already been hacked…

According to https://core.trac.wordpress.org/browser/trunk/src/wp-includes/pluggable.php?rev=37030#L644, you’re otherwise decreasing your site’s security.

The more pressing issue however is the lack of forward compatibility.

https://secure.php.net/password_hash states that the length of the result when using PASSWORD_DEFAULT may be > 60 characters as algorithms may change over time… which won’t work very well considering wp_users.user_pass is defined as varchar(64) - https://codex.wordpress.org/Database_Description#Table:_wp_users_2

le sigh

@kumathroli I specifically mentioned this only applies to offline attacks once your site has been “compromised” in this follow-up post. It’s still an improvement in security regardless. It’s better security against your users having their plain text passwords figured out.

In terms of the table: https://core.trac.wordpress.org/ticket/33904 they’ve expanded both that column and user_activation_key to a length of 255.

I’m not exactly sure what you mean by the decrease in security from this line $pass_frag = substr($user->user_pass, 8, 4);. Could you explain that more?

This will include the (known) cost value

<?php
$hash = password_hash('test', PASSWORD_BCRYPT);
echo $hash;
echo "\n";
echo substr($hash, 8, 4);
$2y$10$utOsf/wG8b/DCl3FmfcvQeLZXgLB8fVxextkCFpQ6VXR9KGpz6KCq
tOsf

The Bcrypt cost is 10 followed by $. After that starts the random salt.

@swalkinshaw is correct. Those identifiers are what make the hashes “portable.” There is nothing wrong with making this information available. It is absurd to assume that it isn’t available during an offline attack (which is what we’re discussing here). Such a presumption violates Kerckhoffs’s principle.

@kumathroli’s security through obscurity approach infamously fails miserably.

I can always respect someone admitting to being wrong. This post was written well and does a good job of clarifying. Well done.

Is the default WordPress security improved at all when upgrading to PHP 7.0?

Are there any known issues with using the bcrypt plugin with PHP 7.0?

No and no