◦ Comprehensive security
◦ 24/7 support
WordPress Guide → Security → Salt Keys
WordPress salts: what they are and how to change them
WordPress salts are random strings of characters stored in your wp-config.php file that WordPress uses to encrypt the cookies it creates when you log in.
They work with WordPress security keys to make your login information difficult for attackers to read or forge, protecting your site from session hijacking and various cookie-based attacks.
If you’ve never thought about WordPress salts, your site is probably fine. But they’re worth understanding, especially if you’ve recently experienced a security incident or accidentally exposed your wp-config.php file.
This guide covers:
- What WordPress salts and security keys are.
- How they work behind the scenes.
- Where to find them in your WordPress installation.
- When you should and shouldn’t change them.
- Three different methods to update them (manual, plugin, and WP-CLI).
- How they fit into broader WordPress security practices.
Get fast, reliable hosting for WordPress
Power your site with the industry’s fastest, most optimized WordPress hosting
What are WordPress salts?
WordPress salts are randomly-generated strings of characters used as cryptographic inputs when WordPress hashes authentication data. Each WordPress installation has four salts, each paired with a corresponding security key. When you log in to your site, WordPress uses these together to create the cookies that keep you authenticated.
When you enter your password, WordPress doesn’t store your actual password in the cookie or session data. Instead, it combines your authentication data with the salts and security keys to produce a hashed value that’s stored in your browser cookies. Without the right salt, the same password would produce a different hash on a different site, which means even if someone steals your authentication cookie, they can’t reverse-engineer your password from it.
A typical WordPress salt looks something like this:
define('AUTH_SALT', 'eZyT)-Naw]F8CwA*VaW#q*|.)g@o}||wf~@C-YSt}(dh_r6EbI#A,y|nU2{B#JBW');The string itself is meaningless to humans. To WordPress, it’s a critical piece of the puzzle that makes your authentication system work securely.
Salts vs. security keys
People often use ‘WordPress salts’ and ‘WordPress security keys’ interchangeably, but they’re technically two different things that work together:
- Security keys (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY) are the primary cryptographic constants used for various authentication scenarios.
- Salts (AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, NONCE_SALT) are paired with each key to add randomness to the hashing process.
Each pair handles a specific authentication purpose:
- AUTH is used to authenticate the user when not over SSL.
- SECURE_AUTH is used when the site is accessed over SSL.
- LOGGED_IN is used to check if a user is logged in.
- NONCE is used for WordPress nonces (one-time-use tokens that protect against certain types of attacks).
In total, there are eight constants in your wp-config.php file related to this system: four keys and four salts. The ‘salts’ shorthand often refers to all eight collectively since they work as a unit.
How WordPress salts actually work
To understand why salts matter, it helps to know what happens when you log in.
Here’s the simplified version of the login process:
- You enter your username and password on wp-login.php.
- WordPress hashes the password you entered and compares it to the hashed password stored in the database. If they match, you’re authenticated.
- WordPress creates a session and generates an authentication cookie. The cookie includes your username, an expiration time, and a hash that’s calculated using your salts and security keys.
- The cookie is stored in your browser. Every subsequent request includes the cookie, so WordPress knows you’re logged in.
The salt’s role is in step 3. The hash included in the cookie is calculated from AUTH_KEY, AUTH_SALT, and your authentication data. Without the right salt, an attacker who somehow got hold of the cookie couldn’t forge a valid one, because they’d need the salt to produce the matching hash.
Salts also matter for password storage. WordPress doesn’t store passwords in plaintext (the actual password text). Instead, it stores a hashed version using the wp_generate_password() function and a hashing algorithm. The salts add randomness to this hashing process, so even if two users have the same password, the stored hashes will look completely different.
Without salts, WordPress would still hash passwords, but the hashes would be much easier to crack using precomputed hash tables (commonly called rainbow tables). The salts make those attacks impractical.
Where are WordPress salts located?
WordPress salts are stored in the wp-config.php file, which lives in the root directory of your WordPress installation (the same folder that contains wp-admin/, wp-content/, and wp-includes/).
To find your wp-config.php file:
- Connect to your site via FTP, SFTP, or your hosting provider’s file manager.
- Navigate to the root directory of your WordPress installation (often called public_html, www, or the name of your site).
- Look for wp-config.php.
Open the file in a text editor and look for the section labeled Authentication Unique Keys and Salts. It looks like this:
/**
* Authentication Unique Keys and Salts.
*
* Change these to different unique phrases!
* You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
*
* @since 2.6.0
*/
define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');
define('AUTH_SALT', 'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT', 'put your unique phrase here');
define('NONCE_SALT', 'put your unique phrase here');If you see literal ‘put your unique phrase here’ strings instead of long random characters, that’s a serious problem. It means WordPress is using its placeholder values, and your site has no real cryptographic protection on its authentication. Generate proper salts and replace them immediately.
For most WordPress installations created in the last several years, the salts will already be filled in with real random strings.
When should you change WordPress salts?
This is where current best practice has shifted from what older guides recommend.
When should you change WordPress salts?
Change your WordPress salts when there’s a specific reason to believe the existing ones may no longer be private:
- After a confirmed security breach of your site (malware infection, unauthorized admin access, suspicious user accounts).
- After accidentally exposing wp-config.php (committing it to a public repository, leaving a backup file accessible on the server, sharing it in a support thread).
- After a leaked backup file that included wp-config.php contents.
- After firing a developer or contractor who had access to your wp-config.php.
- When migrating to a new host, the old environment had wp-config.php access by previous administrators.
- If your salts still contain the placeholder ‘put your unique phrase here’ values.
There is no strict rule for how often you should change your salt keys, but doing so periodically, such as every six months to a year, is advisable.
When NOT to change salts
Older WordPress security guides recommend rotating salts on a fixed schedule (every six months, every year, etc.). This advice is outdated, and current security thinking is that calendar-based rotation provides no meaningful security benefit while creating support issues.
Specifically, changing salts on a fixed schedule:
- Logs out every active user immediately. For a small blog, this is fine. For an ecommerce store, membership site, or LMS, this can affect dozens or hundreds of users mid-session.
- Doesn’t actually improve security unless there’s a reason to believe the old salts may have been compromised.
- Can break integrations. Some plugins use the WordPress salts when storing API keys, encryption tokens, or other sensitive settings. Changing salts can require reconfiguring these integrations.
Rotate salts only when trust is broken. If nothing has been exposed and your site is healthy, your time is better spent on plugin updates, backups, login protection, two-factor authentication, and malware scanning.
How to change WordPress salts: 3 methods
There are three reliable ways to update your WordPress salts. Pick the one that fits your situation best.
Method 1: Manually update wp-config.php
The manual method gives you direct control and works on any WordPress installation. You’ll need FTP, SFTP, or file manager access.
Step 1: Generate new salts
Go to the WordPress.org secret-key service in your browser. This URL generates a fresh set of eight salts and keys formatted for direct paste into wp-config.php. The output looks like this:
define('AUTH_KEY', '|9X(zM5p..long random string..>3v#');
define('SECURE_AUTH_KEY', ':kT9w$Q..long random string..lLpN#');
... and so on for all eight valuesEach time you visit the URL, you get a fresh, unique set of salts. Don’t reuse the same set across multiple sites or someone else’s published example.
Step 2: Back up wp-config.php
Before editing, download a copy of your current wp-config.php to your local computer. If something goes wrong, you can restore it.
Step 3: Open wp-config.php for editing
Use your hosting control panel’s file editor, FTP, or SFTP to open the file. The file is in your WordPress root directory.
Step 4: Replace the old salts
Find the Authentication Unique Keys and Salts section. Delete the existing eight define() lines (the entire block between the section comment and the next section). Paste in the new eight lines you generated in Step 1.
Step 5: Save the file
Save your changes and upload the file back to the server (if you downloaded it for editing).
Step 6: Test
You’ll be logged out of WordPress automatically (the salt change invalidates your existing session). Log back in to confirm everything works. If you can log in, the salt rotation was successful.
If you can’t log in, restore your backup of wp-config.php and try again. Common causes of issues: stray spaces or quote marks in the pasted values, missing line endings, or accidentally deleting other parts of the file.
Method 2: Use a plugin
If you’d rather not edit wp-config.php manually, the Salt Shaker plugin can rotate salts from inside the WordPress dashboard.
Here are the steps to use it:
- From your WordPress admin dashboard, go to Plugins > Add New.
- Search for ‘Salt Shaker’.
- Install and activate the plugin.
- Go to Tools > Salt Shaker.
- Click Change WordPress Salts.
- The plugin updates wp-config.php for you, and you’ll be logged out.
Salt Shaker also includes an option to schedule automatic salt rotation. Given the current best practice (rotate when trust is broken rather than on a schedule), this feature is worth understanding before enabling.
Scheduled rotation can log users out at awkward times and may break plugin integrations that rely on the salt values for encryption. For most sites, manual rotation when needed is the better approach.
If your site has been compromised, don’t use a plugin running inside the compromised WordPress install to rotate salts. Clean the site first, then handle the rotation manually or via WP-CLI.
Method 3: Use WP-CLI
For sites with command-line access (most managed WordPress hosting, VPS, or dedicated servers), WP-CLI provides the cleanest way to rotate salts:
wp config shuffle-saltsThat single command regenerates all eight keys, salts, and updates wp-config.php in place. WP-CLI uses the same WordPress.org secret-key service under the hood, so the resulting salts are cryptographically sound.
WP-CLI is particularly useful when you’re working on a site you’ve just secured after a breach, since you can run it without going through the dashboard. It also works in deployment scripts if you’re automating site setup.
How WordPress salts fit into WordPress security
Changing your salts is one piece of WordPress security. It addresses a specific concern (cookie-based attacks and stolen authentication data), but it doesn’t help with the issues that are actually more common, like outdated plugins with known vulnerabilities, weak admin passwords, or brute force attacks on the login page.
For broader WordPress security, the practical priorities are:
- Keep WordPress core, plugins, and themes updated. Per Patchstack’s 2026 State of WordPress Security report, 11,334 new vulnerabilities were discovered across the WordPress ecosystem in 2025, with 91% in plugins. The weighted median time between vulnerability disclosure and exploitation is just five hours.
- Use strong, unique admin passwords combined with two-factor authentication. Brute force attacks on wp-login.php are a constant background noise on every WordPress site.
- Install a WordPress security plugin that handles ongoing scanning, firewall protection, and login security.
- Use HTTPS everywhere with a valid SSL certificate. This protects login cookies in transit, which is one of the main reasons salts matter in the first place.
- Run automated daily backups stored off-server. Backups are your insurance against incidents that get past your other defenses.
How Kadence Security helps
Kadence Security handles most of the security vectors that matter for WordPress sites in one plugin. For the broader context around salts and authentication security, Kadence Security includes:
- A real-time firewall that filters suspicious traffic before it reaches WordPress, blocking common attack patterns at the perimeter.
- Brute force protection that limits login attempts and automatically blocks repeat offenders, drawing on a threat intelligence network.
- Two-factor authentication is built into the plugin for every account that needs it.
- Patchstack virtual patching that protects against plugin and theme vulnerabilities before official patches are released.
- Automated malware scanning that flags suspicious files before they become a problem.
- File change detection that alerts you when wp-config.php or other critical files are modified unexpectedly.
The last point is particularly relevant for salts: if an attacker were to modify your wp-config.php to inject their own salt values (which would let them forge authentication cookies), Kadence Security would detect the change and alert you within hours rather than weeks.
For most WordPress sites, the combination of Kadence Security and managed WordPress hosting is enough to keep the security issues that actually compromise sites under control. Salt rotation is then something you do when needed (after a breach, after exposure) rather than as a routine maintenance task.
FAQs about WordPress salts
Common questions about WordPress salts that come up beyond what’s covered above.
The reference to ‘WP Salt PHP’ is usually about the WordPress core function wp_salt(), which is the internal function WordPress uses to retrieve or generate salts during authentication. You don’t typically interact with this function directly; it runs automatically as part of the WordPress login flow.
WordPress uses bcrypt for password hashing as of WordPress 6.8 (released in April 2025). Before that, WordPress used phpass (PHP Password Hashing Framework) with portable hashes. Both algorithms are designed to be computationally expensive, which makes brute-force cracking of stored passwords impractical even if an attacker gains database access. The salts are part of the broader system that makes this hashing effective.
If done correctly, no. The risks come from making mistakes during the wp-config.php edit: stray characters, missing quotes, accidentally deleting other configuration values, or corrupting the file. Always back up wp-config.php before editing. If your site stops working after a salt change, restoring the backup will get you back to a working state, and you can try again.
Some plugins use the WordPress salts when encrypting their own data (API keys, integration tokens, etc.). For these plugins, you may need to reconfigure the affected settings after a salt rotation. Most well-designed plugins handle this gracefully, but it’s worth being aware of if your site relies on integrations with stored credentials.
Get to grips with WordPress salts
WordPress salts are a genuinely important part of how WordPress protects your authentication system. They’re already in place on every healthy WordPress installation. Most site owners never need to think about them.
When you do need to think about them, rotate them with intent rather than on a schedule. After a security breach, after accidentally exposing wp-config.php, or after firing someone with server access are all good reasons to rotate.
For everything else for WordPress security (keeping software updated, using strong passwords, running backups, installing a security plugin), Kadence Security handles the routine work in one place. Combined with Liquid Web’s managed WordPress hosting, you’ll cover the security that actually leads to most WordPress compromises.
Additional resources
Comprehensive guide to securing WordPress with ModSecurity
→
This guide provides a comprehensive overview of how to use ModSecurity to enhance the security of your WordPress site.
WordPress malware removal techniques to try →
Learn how to remove malware from your WordPress site and protect it from future threats.
Why security matters for WordPress enterprise hosting
→
Use the blog as your guide to attacks to watch out for, security best practices, and steps to improve the WordPress protection you already have.