The Complete Engineering Guide to WordPress Authentication, Password Hashing, and Database Recovery
Understand the evolution from phpass MD5 to modern bcrypt in WordPress 6.8+, the mechanics of HMAC-SHA-384 pre-hashing, BLAKE2b fast token verification, and step-by-step database user_pass restoration.
The Evolution of WordPress Password Security: From MD5 to Modern Bcrypt
Powering over 40% of the world top 10 million websites, the WordPress content management system has undergone a multi-decade evolution in its password storage architecture. In early releases (WordPress 1.x through 2.4), user passwords were saved as raw single-iteration MD5 hashes. In that era, the emergence of precomputed rainbow tables made un-salted MD5 hashes trivially reversible within fractions of a second.
In 2008 with WordPress 2.5, core engineers introduced the phpass framework. It implemented an iterated, salted MD5 hashing scheme identified by the classic $P$B prefix in the wp_users database table. While phpass provided acceptable protection against offline brute-force attacks in the late 2000s, modern GPU clusters and specialized ASIC hardware can compute billions of MD5 operations per second, rendering phpass increasingly obsolete.
Starting in WordPress 6.8+, core developers modernized the authentication pipeline, adopting bcrypt via PHP native password_hash() for human credentials, alongside BLAKE2b for high-entropy machine tokens. This upgrade aligns WordPress with contemporary National Institute of Standards and Technology (NIST) and OWASP security recommendations.
The 72-Byte Bcrypt Limitation and WordPress SHA-384 Pre-Hashing
While bcrypt is universally recognized as an exceptional password hashing algorithm due to its configurable work factor and memory-hardness, it contains a critical architectural quirk: bcrypt truncates input strings at exactly 72 bytes.
If a user enters a 100-character passphrase, native bcrypt only processes the first 72 characters, silently ignoring the remaining 28 characters. An attacker attempting to guess the password only needs to match the first 72 bytes.
To eliminate this vulnerability without breaking backward compatibility, WordPress 6.8+ implements an ingenious two-stage hashing protocol:
Stage 1: Pre-Hashing with HMAC-SHA-384
The plaintext password is first passed through HMAC-SHA-384 using the static secret key 'wp-sha384'. This mathematically condenses passphrases of any arbitrary length (whether 10 characters or 5,000 characters) into a fixed-length 48-byte binary digest.
Stage 2: Base64 Encoding
The 48-byte binary digest is Base64-encoded, producing an exact 64-character ASCII string. Because 64 characters is strictly less than bcrypt 72-byte ceiling, no truncation ever occurs!
Stage 3: Bcrypt Salting and Hashing
The 64-character digest is passed to PHP password_hash() using PASSWORD_BCRYPT with cost factor 10, and prepended with the '$wp$' prefix, generating strings formatted as $wp$2y$10$...
Comparison of WordPress Hashing Algorithms Across Core Functions
WordPress employs distinct cryptographic hashing functions depending on whether credentials are human-generated or machine-generated:
| Core Function | Underlying Algorithm | Database Prefix | Execution Speed | Target Use Case |
|---|---|---|---|---|
| wp_hash_password() | bcrypt + HMAC-SHA-384 | $wp$2y$10$ | Slow (~80-100ms, Key Stretching) | Standard user and admin login passwords in wp_users |
| wp_fast_hash() | BLAKE2b (via ext-sodium) | $generic$ | Sub-millisecond (<0.5ms) | Application passwords, REST API tokens, reset keys |
| wp_hash() | HMAC-MD5 with site salts | None (32 hex chars) | Extremely fast (<0.1ms) | CSRF nonce verification, session cookie authentication |
| Legacy phpass | Iterated salted MD5 | $P$B | Moderate (~5ms) | Pre-6.8 legacy password hashes awaiting login re-hash |
Step-by-Step Guide: Resetting WordPress Admin Passwords via MySQL
When a site administrator is locked out of their WordPress dashboard due to a lost password or broken two-factor authentication (2FA) plugin, direct database recovery is required:
- Generate Hash: In the tool above, enter your desired new plaintext password, select the "User Password (bcrypt)" algorithm, and copy the generated
$wp$2y$10$...hash string. - Open phpMyAdmin / Database CLI: Access your web hosting control panel (cPanel, Plesk, RunCloud, or terminal MySQL client) and open the database associated with your WordPress installation.
- Navigate to wp_users Table: Click on the
wp_userstable (or your custom prefix, such aswp_5x_users) and click "Browse". - Edit the Admin Record: Locate the row corresponding to your administrative username in the
user_logincolumn, click "Edit", and paste your generated hash directly into theuser_passfield. - Save Changes: Click "Go" or save the row. Navigate to your website
/wp-login.phppage and log in with your new plaintext password.
Transparent Automatic Password Upgrades Upon User Login
Upgrading an enterprise website with millions of registered users to WordPress 6.8+ does not force mass password resets. The WordPress core authentication handler performs seamless lazy migration:
When a user submits their credentials at the login prompt, wp_check_password() inspects the stored hash in the database. If the hash begins with the legacy $P$ prefix, it computes the phpass check. If valid, WordPress immediately invokes wp_hash_password() on the submitted plaintext string, generates a state-of-the-art bcrypt hash, and replaces the legacy hash in the database before completing the login redirect. Through this mechanism, active users are upgraded automatically without disruption.
Security Hardening: WordPress Authentication Salts and Secret Keys
Beyond the individual password hashes stored in wp_users, WordPress utilizes eight cryptographic salt keys defined in wp-config.php: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, and their corresponding salt pairs.
These 64-character randomized strings provide cryptographic entropy for signing browser authentication cookies and CSRF nonces. If a site administrator suspects an unauthorized intrusion or wants to forcibly terminate all active user sessions across the entire web application, changing the salt keys in wp-config.php immediately invalidates all existing cookie signatures, requiring every user to re-authenticate with their password.
DevOps Automation: Managing Passwords via WP-CLI
For systems engineers managing high-availability WordPress multisite clusters, manual phpMyAdmin database edits are slow. The WordPress command-line interface (WP-CLI) provides automated administrative password management:
WP-CLI communicates directly with core PHP APIs, ensuring all pre-hashing, validation hooks, and salt associations are strictly observed.
Frequently Asked Questions (FAQs)
100% Client-Side Privacy and Security Guarantee
Your confidential administrator credentials, client database passwords, and generated hashes remain strictly confidential. The HiFi ToolKit WordPress Hash Generator executes all HMAC-SHA-384 pre-hashing, bcrypt cost derivations, and BLAKE2b token syntheses 100% locally inside your client web browser JavaScript engine. Zero plaintext passwords, hashed outputs, or site credentials are ever transmitted over the network or logged in remote cloud databases. Systems administrators, WordPress agencies, and DevOps engineers can generate production database credentials with total operational confidence.
