When you can reach the database but not the admin screen, the Drupal password hash generator turns a plaintext password into the exact $S$ string your site stores. Instead of waiting on a forgot password email that never arrives, you pick a new password, copy the hash and run one update statement. The sections below show how to generate Drupal password hashes, how the string is built and what changes from Drupal 10.1 onward.
How the Drupal Password Hash Generator Builds a $S$ Hash
Drupal's classic format is its own variant of phpass. The algorithm hashes the salt and your password together with SHA-512, then the digest is iterated through the same function again and again, mixing the plaintext in on every pass. The loop is deliberately slow: anyone holding a stolen dump has to repeat all of it for every single guess. Run the argon2 hash generator whenever you need another one — it only takes a few seconds.
$$h_{n} = \text{SHA-512}\left(h_{n-1} + \text{password}\right)$$The default loop count is \(2^{15}\), which is 32,768 rounds, and the count is recorded inside the stored string so the site knows how many passes to repeat when you log in later.
SHA-512 Rounds and the 55 Characters Drupal Keeps
A SHA-512 digest is 64 bytes. Drupal encodes it with the phpass alphabet (./0-9A-Za-z) and the result is truncated so that the finished string fits the width of the column: three characters of marker, one cost character, eight characters of salt and 43 characters of digest. That is why a correct hash is always 55 characters long, and a shorter paste means something was cut off on the way into the database.
Salt, Marker and Cost Character
The salt is eight random characters picked from the same alphabet, and it is stored in plain sight right after the cost character. Its job is to make two identical passwords produce different strings, so no one can spot shared passwords by comparing the column. The $S$ marker tells Drupal which scheme to use, and the single letter after it encodes the rounds as a power of two.
Worked Example: Generating a Hash for Your Own Password
Take the new password Harbor-Lantern-4471 and the salt k7Tq2WmX. The cost character is D, the fifteenth symbol in the alphabet, so the loop runs \(2^{15} = 32768\) passes. After those passes the generator keeps the first 43 encoded digest characters and joins everything together: Use the free hmac generator to get a result in seconds — right in your browser.
$S$Dk7Tq2WmXL/Qh.KPv3ra19gGtQJhDZgJmqI87u5BWJF5VNPGPP2v| Part | Characters | Value in the example |
|---|---|---|
| Marker | 3 | $S$ |
| Cost | 1 | D (215 passes) |
| Salt | 8 | k7Tq2WmX |
| Digest | 43 | L/Qh.KPv3ra19gGtQJhDZgJmqI87u5BWJF5VNPGPP2v |
Count the pieces and you get 3 + 1 + 8 + 43 = 55. Different password, different result: change one character of Harbor-Lantern-4471 and not a single digest character survives, while the same salt and password always reproduce this string exactly.
Which Table Holds the Hash in Drupal 7 and Drupal 8
The same hash goes into a different place depending on the release you run. The old column is users.pass; every later release moved it to a field table, and following an old guide against a newer site is the classic reason a manual reset appears to succeed but never lets you in.
Writing the Update Statement for users_field_data
Run this against your database, replacing the username and keeping the single quotes around the hash, since the $ characters would otherwise be expanded by a shell:
UPDATE users_field_data SET pass = '$S$Dk7Tq2WmXL/Qh.KPv3ra19gGtQJhDZgJmqI87u5BWJF5VNPGPP2v' WHERE name = 'admin';Check that one row changed, clear the caches and log in with the plain password. On the next successful login Drupal may rewrite the value in its newest format on its own.
Bcrypt and the Password Service in Drupal 10 and Drupal 11
From release 10.1, core stopped using its own scheme. The new password service wraps PHP's password_hash(), password_verify() and password_needs_rehash(), so new hashes are bcrypt strings beginning with $2y$. Older values still verify, which is why $S$ keeps working after an upgrade.
Password Compatibility and the Legacy Hash
The previous algorithm lives on in the Password Compatibility module, installed during the upgrade or by migrations from older sites. Each user's legacy hash is replaced with a bcrypt one the first time that user logs in. Keeping the module around forever undoes part of the hardening, so remove it once most accounts have been rewritten, and watch the cost: PHP 8.4 raised the default bcrypt cost from 10 to 12.
Finding Legacy Hashes with SQL
This query lists every account still on the old format, because new values all start with $2y$:
SELECT uid, name, mail FROM users_field_data WHERE pass NOT LIKE '$2y$%';If you generate a bcrypt value yourself, remember that older releases cannot verify it. Match the hash format to the version your site actually runs.
Resetting a Staging Admin Login with a Drupal Hash Generator
Dariusz restores last night's backup onto a staging server running Drupal 10.0.9 and finds that nobody remembers the events_admin password. The server has MySQL but no terminal for the web user, so the shell tools are out. He picks the new password Quarry-Ferry-2093 and enters it into the generator with the version set to 10.0, because 10.0 still verifies the old scheme and bcrypt is not yet the default there.
The tool returns $S$DWn3zR9aBByerBL3zQF/1bcN8/knKeuAlvjnLJaykbiBEJWaC2re. Before copying it he checks the three things that give it away: it starts with $S$D, the salt Wn3zR9aB follows, and the whole string is exactly 55 characters. A 54-character paste, which is what a trimmed clipboard produces, would never verify.
He runs the update against users_field_data, because a 10.x database has no users.pass to write to, and the client reports one row matched and one changed. Logging in with events_admin and the new password works on the first try. Then he reruns the query from the change record, pass NOT LIKE '$2y$%', which now lists 412 accounts, including this one, still on the old format. Since the production site moves to 10.2 next sprint, he writes down the next action: leave Password Compatibility enabled through the upgrade, and revisit it once the legacy count drops below the 5% of active users he set as the cutoff.
Drush and the Hash Script: When a Shell Beats a Browser
If you have shell access, drush user:password does the job with the site's own code and no chance of writing the wrong column. Core also ships a hash script, core/scripts/password-hash.sh, that prints a hash for any quoted plaintext you pass it, and Drush needs nothing else once it is installed. A browser-based generator earns its place when you have a restored backup, a host with no terminal or a site you are recovering rather than running.
- With a shell: use the script or the Drush command and skip manual SQL.
- Without a shell: generate the hash in your browser, then apply it through your database client.
- For a throwaway user on a development copy: either route works, as long as the column matches your release.
A plain password generator module only produces plaintext, so you still need a hash generator to get the stored $S$ value.
Locked Out? Recovering a Drupal Admin Login
Start with the least invasive option: ask for a one-time login link as a site administrator and change a password from inside the site. If that email never comes, the generator route needs only database access. Create the hash, update the admin row, then log in with the new password. If a migration left you without the phpass module, enable it, or temporarily set $settings['update_free_access'] = TRUE; in settings.php and visit update.php, then switch that setting back off immediately.
- Take a backup of the database before changing anything.
- Generate the hash for the new password.
- Apply it to the
passcolumn for the right username. - Clear caches, log in and change the password again from your profile page.
The same flow helps when you migrate users between sites or seed a staging copy: generate a known value for each test account's hash and sign in as that user.
Security Notes for the Drupal Hash You Generate
Treat every plaintext password you type into a generator as sensitive. Use a tool that runs in your browser and uploads nothing, pick a password you will change right after login and never keep the SQL in a ticket or chat history. Implementations should be checked against published test vectors; the phpass reference hash for a known password is the usual benchmark.
Each CMS, such as WordPress or Joomla, stores a different format in a different column, so the $S$ hash is Drupal-only: never paste it into another application's user table.
Frequently Asked Questions
- Does this match Drupal 8, 9, or 10's password hashes?
- No -- Drupal 8 and later switched to PHP's built-in password_hash() function, which uses bcrypt by default. That's exactly what this site's Bcrypt Generator produces, so use that tool instead if you're targeting Drupal 8+. This tool specifically replicates Drupal 7's own $S$-prefixed scheme.
- How does Drupal 7's algorithm work?
- It's structurally the same "stretched hash" approach as the classic phpass library (the same design WordPress's legacy $P$ hashes use), but with SHA-512 as the underlying hash instead of MD5: the password is combined with a random salt and hashed repeatedly (2^15 = 32,768 times by default), then the result is encoded with a custom base64-like alphabet and truncated to Drupal's fixed 55-character hash length.
- How was this verified to be correct?
- By fetching Drupal core's actual includes/password.inc source directly from Drupal's own GitHub repository and implementing the documented algorithm exactly as specified -- including a detail easy to get wrong (the full SHA-512 output is base64-encoded to 86 characters, then the combined string is truncated to exactly 55 characters, not encoded to 55 directly). Cross-checked byte-for-byte between an independent Python re-implementation and this tool's actual browser JavaScript before shipping.
- Can I insert this hash directly into a Drupal database?
- Yes -- the generated string matches the exact format Drupal 7's users table pass column expects, so it can be used directly in a manual database update or migration script for a Drupal 7 site.
- Is my password sent anywhere?
- No. The entire hash is computed locally using the Web Crypto API -- your password and the resulting hash are never transmitted to a server or stored.