WordPress Password Hash Generator
Generates a phpass hash WordPress still accepts, in your browser, with the SQL to use it and a straight account of why a reset email or WP-CLI is better.
The hash is generated in your browser, from its own random source.
Rounds 8,192, from 2 to the power of 13
This runs in your browser and there is no request to make: the password
is hashed where you typed it. That is worth checking rather than
trusting, for this tool and for every other one that asks for a
password.
WordPress 6.8 and later write bcrypt for new passwords, with a $wp$2y$
prefix. A phpass $P$ hash is still accepted, and the next successful
login replaces it with bcrypt. So writing one into the database is a
temporary state by design rather than a downgrade you have to undo.
The iteration count is the cost. 8,192 rounds of MD5 is slow enough to
make a stolen database expensive to attack and fast enough that a login
is imperceptible. MD5 on its own, which WordPress used before 2.5, is
neither: a modern graphics card tries billions a second.
The salt is in the hash, which is why two hashes of the same password
look nothing alike and why verifying needs no other stored value. It
also means a stolen hash cannot be looked up in a rainbow table, which
is what salting is for.
A direct SQL update does not clear session tokens. Anybody already
logged in as that user stays logged in, because those live in user meta
rather than in the password. Changing the password through WordPress
clears them.
Reach for this last. A reset email needs no access; WP-CLI needs a shell
and does the hashing properly; editing the users table is the option
left when the others are gone, and it is the one most likely to be done
at 2am.
Never paste a password into a tool you have not checked, including this
one. View the source, look for a fetch, or disconnect from the network
and watch it still work.
Output is valid and updates as you type.
Fix the highlighted fields to update the output.
This exists for one afternoon: the one where you are locked out of wp-admin, the reset email is not arriving, and all you have is database access.
WordPress 6.8 and later write bcrypt for new passwords, with a $wp$2y$ prefix so WordPress can tell its own
hashes from anybody else’s. Every version since 2.5 also still accepts a phpass portable hash, the $P$ kind,
and replaces it with bcrypt the next time that user logs in. So a $P$ hash written straight into
wp_users.user_pass is a working password today, and it stops being a phpass hash on the first login without
anybody doing anything.
The hashing happens in your browser, from the browser’s own random source. There is no request to make, which is a fact you can check in the network tab rather than a promise to believe.
How to use
- Put in the password. It is hashed locally.
- Check the two better options above the SQL: a reset email needs no access at all, and WP-CLI does the hashing with whatever algorithm your version uses.
- If SQL really is all you have, copy the
UPDATE, run it, log in once, then change the password properly through the profile screen.
Example
Hash $P$BWzNbe7HDdpP82VCMa72/E.4NYlIK40
format phpass portable, which every WordPress since 2.5 accepts
rounds 8,192, from 2 to the power of 13
salt the eight characters after the prefix
verifies yes, checked against the same implementation
The better options first
a reset email the login form's "Lost your password?" link
WP-CLI wp user update admin --user_pass='…'
And the SQL, if that is all you have
UPDATE wp_users SET user_pass = '$P$BWzNbe7HDdpP82VCMa72/E.4NYlIK40' WHERE user_login = 'admin';
Afterwards
log in once which replaces this hash with a bcrypt one
then change it through the profile screen, which also clears the other sessionsPaste an existing user_pass value into the checker and the tool names its format: phpass, bcrypt, the
$wp$ prefixed bcrypt, or a plain MD5 from before 2.5, which is worth knowing about because it means the
password was stored unsalted.
Pitfalls
Try the reset email first. It requires no database access, no SQL and no tool. This is for when it has already failed.
WP-CLI beats SQL. wp user update admin --user_pass='…' makes WordPress do the hashing, so the format
matches the version you are on and the user’s sessions are cleared with it.
A direct SQL update does not clear sessions. Session tokens live in user meta. Anybody already logged in as that user stays logged in, which matters if the reason you are here is that somebody else got in.
Change the password properly afterwards. Logging in once upgrades the hash; changing the password through WordPress does that and clears the other sessions.
Back up the row first. SELECT user_pass FROM wp_users WHERE user_login = 'admin'; takes a second and
means a typo is recoverable.
Do not reuse a hash between users. Two identical user_pass values tell anybody who reads the table that
two accounts share a password.
Never paste a password into a tool you have not checked. Including this one. View the source, look for a network call, or disconnect and watch it still work.
Compatibility
Runs in the browser. The salt comes from the browser’s cryptographic random source, so the page renders a placeholder at build time and generates a real hash when it loads: a hash baked into the published HTML would be the same for everybody.
The MD5 implementation is tested against the vectors in RFC 1321 and at the block boundaries where padding
usually goes wrong, with every expected digest taken from PHP’s own md5() rather than from memory.
The phpass output is verified against WordPress itself: the hashes in the test suite were each checked with
wp_check_password() before being written down, on WordPress 7.1.2, which also confirms that a phpass hash is
still accepted well past 6.8 and that wp_password_needs_rehash() returns true for one.
Testing the base64 variant against PHP caught a real bug: the increments in phpass’s encoder test the index before advancing it, and doing it the other way produces one character too few whenever the byte count is a multiple of three. Phpass only ever encodes sixteen bytes, so the hashes were correct anyway and the function was wrong.
Frequently asked questions
Is a phpass hash less secure than bcrypt?
$P$ hash written here is
replaced on the next login.