user_activation_key is not hashed in the database

[harrym]

WordPress 3.5.2 does not hash user_activation_key in the database. user_activation_key is a one-time password generated and used during the password reset process.

In combination with another vulnerability that reveals database fields, this value can be used to set a new password for a user account, bypassing the need to extract and brute-force password hashes.

To address this issue, user_activation_key should be hashed in the database, as passwords are.

[NB: I have not attached a patch because the core team have already agreed that they will target a fix for 3.7]

[harrym]

PS: this issue was discovered by Glyn Wintle.

[nacin]

24783.diff​ implements this. Works like a charm.

When someone tries to used an older, unhashed user_activation_key, it changes the error message from "Sorry, that key does not appear to be valid." to "Sorry, that key has expired. Please try again." — and it gives you the form to immediately request a password reset email again.

This way, we don't annoyingly invalidate all existing keys without providing any kind of feedback to a user that loses their password right around the time of an update done by someone else. (Think, especially, a big WP install.)

This will have major implications for BackPress-driven sites like bbPress 1.x (so, a lot of WordPress.org). Please do not commit until we figure out this piece.

[nacin]

Maybe increase the key length to 30?

[nacin]

In 25696:

Hash password reset keys in the database.

All existing, unused password reset keys are now considered "expired" and the user will be told they should try again.

Introduces a password_reset_key_expired filter to allow plugins to introduce a grace period.

fixes #24783.