Open your wp-config.php file and you will find a block of eight lines full of long, random-looking text. Most people scroll past it. Those lines are WordPress salts (and their four sibling keys), and they quietly decide whether a login cookie can be trusted.
Understanding them takes about five minutes, and it gives you one of the fastest ways to throw an intruder out of your site. This article explains what they do, what changes when you replace them, when to rotate them, how to do it by hand and by command, and the mistakes that undo the whole point.
What WordPress Salts and Security Keys Do
Here is the block as it appears in wp-config.php:
define( 'AUTH_KEY', '...' );
define( 'SECURE_AUTH_KEY', '...' );
define( 'LOGGED_IN_KEY', '...' );
define( 'NONCE_KEY', '...' );
define( 'AUTH_SALT', '...' );
define( 'SECURE_AUTH_SALT', '...' );
define( 'LOGGED_IN_SALT', '...' );
define( 'NONCE_SALT', '...' );
Four are keys and four are salts. People use "salts" for the whole set, and the pairing is deliberate: each key has a matching salt, and WordPress combines them to make its secret.
Here is what they are for. When you sign in, WordPress gives your browser a cookie, a small file that says "this person already signed in". Without protection, anyone could write a cookie that says "I am the administrator". WordPress prevents that by signing the cookie with a secret that only your server knows. The keys and salts are that secret.
- AUTH_KEY and AUTH_SALT are used for the cookie that proves you are signed in on the normal (non-HTTPS) admin.
- SECURE_AUTH_KEY and SECURE_AUTH_SALT do the same for the secure, HTTPS cookie.
- LOGGED_IN_KEY and LOGGED_IN_SALT are used for the cookie that says you are signed in while viewing the site.
- NONCE_KEY and NONCE_SALT protect the short-lived tokens WordPress uses to check that a request came from a real form. If you want the details, see our article on the WordPress nonce.
Think of it like the stamp on a bus ticket. Anyone can print a ticket, but only the company's stamp makes it valid. Change the stamp and every ticket printed with the old one stops working at the gate.
Salts Are Not Passwords
A common worry is that salts protect your password. They do not. Your password is stored as a hash in the database, with its own method. The keys and salts protect cookies and tokens. That is why changing them does not reset anyone's password.
What Happens When You Change Them
The answer is simple: everyone is signed out, including you. Every cookie that was signed with the old values no longer matches, so WordPress treats the visitor as signed out. Nothing else changes:
- Passwords stay the same.
- Posts, pages, orders and settings are untouched.
- Open forms can fail once, because the nonce values change too. Refreshing the page fixes it.
- Anything stored encrypted with a key derived from the old values may need attention. Some plugins do this, so check the plugin's notes if it keeps secrets for you.
That last point is why Stack Guard re-encrypts its own two-factor secrets and licence key when it rotates keys, so two-factor settings keep working afterwards. Not every plugin does, so a quick test after rotating is wise.
Key takeaway: Rotating salts is the "sign everyone out, right now" button. It is the only way to cancel a stolen login cookie without knowing which account it belongs to.
When to Rotate Your WordPress Salts
You do not need to change them daily, but there are clear moments when you should.
After Any Sign of a Break-In
If you suspect a hack, rotating the keys is one of the first things to do after you take a backup. Changing one password does not help if the attacker holds sessions for other accounts, or a backdoor that mints its own. New salts cancel every cookie at once. Our article on the signs your WordPress site has been hacked shows what to look for, and the recovery guide has the whole order of operations.
After a Backdoor Is Found
A WordPress backdoor can let someone back in without a password. Cleaning the files is half the work. Rotating the salts removes any session the attacker already holds.
When Someone With Access Leaves
A developer, an agency or an employee who had admin access might have a browser still signed in, or a copy of wp-config.php in their files. Changing the salts when they leave closes both.
After a Leaked Backup or Shared Config
If a backup file ended up somewhere public, or wp-config.php was emailed around, assume the values are known and change them. Do the same for the database password, which sits in the same file.
On a Schedule
A regular change limits how long any stolen cookie can be useful. Every few months is a reasonable rhythm for a typical business site. Pick a quiet time, because everyone gets signed out. For a site with a lot of logged-in customers, such as a membership site or a shop, go less often and give warning.
| Situation | Rotate? |
|---|---|
| Site hacked or suspected hack | Yes, immediately |
| Backdoor or malware found | Yes, after cleaning |
| Staff or contractor with admin access leaves | Yes |
| Config file or backup leaked | Yes, and change the database password |
| Routine care | Every few months, at a quiet time |
| Nothing has happened and you have just updated plugins | No |
How to Rotate WordPress Salts by Hand
You need access to your files (through your host's file manager or SFTP) and about five minutes.
- Take a backup of the site, or at least a copy of
wp-config.php. A typo in this file can take the site down, and a copy gets you out. - Open the official generator at api.wordpress.org/secret-key/1.1/salt/. It returns a fresh block of eight
define()lines each time you load it. - Copy the whole block.
- Open
wp-config.phpand find the existing eight lines. - Replace all eight lines with the new block. Make sure you do not leave any old lines behind and do not break the quotes.
- Save the file and upload it.
- Load your site. You will be signed out. Sign in again.
If something goes wrong, the usual cause is a stray quote or a missing semicolon. Put your backup copy back and try again.
Pro tip: Use the generator over HTTPS, as in the link above, and never paste a set from a blog post or a forum. Keys that are published anywhere are no longer secret.
How to Rotate Salts With WP-CLI
If you have command line access, WP-CLI does the whole job in one line. The command reference describes wp config shuffle-salts as refreshing the salts defined in your wp-config.php file.
wp config shuffle-salts
It prints Success: Shuffled the salt keys. when it works. Without arguments it replaces the default WordPress core keys. You can pass the names of specific keys, and --config-file points it at a different file. There is also an --insecure flag, which retries the download without certificate checks if the secure connection fails. Avoid that one, because it exposes the request to interception.
This is the neatest method for hosts that give you WP-CLI, and it is easy to script for a scheduled rotation.
How Stack Guard Handles Salts
You can do all of this by hand, but a few things make it nicer in practice. The Hardening tab in Stack Guard has a Security keys section. Its security keys documentation explains the full flow.
- Rotate Now (Free). One click and a confirmation replaces all eight values. Before it writes, Stack Guard saves a copy of
wp-config.phpand checks that the new file is valid, so a typo cannot take the site down. Ifwp-config.phpis not writable, it tells you, and you can fall back to the by-hand method above. - Reminders (Free). Choose a schedule and Stack Guard emails you when it is time. You stay in control of when everyone is signed out.
- Automatic rotation (Pro). Stack Guard changes the keys daily, weekly or monthly at a time you choose, and can email you when it happens. Pick a quiet hour, such as 3 in the morning.
The panel also shows when the keys were last changed and how many of the eight are properly set, which is a quick way to spot a site still using the placeholder text from the sample config. See the Hardening feature page for the rest of that tab.
Common Mistakes With WordPress Salts
Leaving the Placeholder Text
A fresh wp-config-sample.php ships with lines that say put your unique phrase here. If someone copied that file and never replaced the values, the "secret" is public. Check yours.
Committing wp-config.php to Git
This one catches developers. A wp-config.php in a repository, especially a public or shared one, publishes your salts and your database password. Keep it out of version control (add it to .gitignore), and load secrets from environment values on your server where you can. If one has already been committed, rotating the salts and the database password is the fix, because deleting the file does not remove it from the history.
Sharing the Whole File for Support
"Send me your wp-config" is a common request in support threads. Send a version with the database password and keys replaced by xxxx instead. If a full copy has been shared, rotate afterwards. Our wp-config and file permissions guide covers how to protect the file itself.
Rotating Without a Backup
It is a small edit, but it is an edit to the one file WordPress cannot start without. Keep a copy.
Expecting Salts to Fix Everything
Changing salts signs people out. It does not remove a backdoor, update a vulnerable plugin or fix a weak password. After a break-in it is one step in a list, and the rest of the list still needs doing. Pair it with a password reset for administrators, and consider shortening how long sessions last. Our WordPress auto logout article shows how.
A Short Routine to Keep
- Check that all eight values in
wp-config.phpare long and random, not placeholder text. - Keep
wp-config.phpout of Git and out of email. - Rotate after any hack, leaked backup or departure of someone with admin access.
- Set a reminder to rotate every few months at a quiet time.
- After rotating, sign in and test your forms, checkout and any plugin that stores secrets.
Do that and a cookie stolen today stops being useful on a date you choose, not whenever the thief gets bored.