
How to add security keys and salts in WordPress?
- Sajjad
- WordPress, Security
- 09 Sep, 2026
To add security keys and salts in WordPress, generate a fresh set of eight random values from the official WordPress.org secret key generator, then paste them into your wp-config.php file in place of the existing AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, and NONCE_SALT lines. If you have SSH access, the WP-CLI command wp config shuffle-salts does the same thing in one step. Saving new keys immediately logs everyone out, which is exactly why rotating them is a useful response to a suspected compromise.
Keys and salts are a small part of your configuration that play a big role in protecting login sessions. In this guide, you'll learn what they do, how to check whether your site has proper keys, how to add or replace them manually, with WP-CLI, or with a plugin, and when it makes sense to rotate them.
What Are WordPress Security Keys and Salts?
When you log in to WordPress, it doesn't store your password in a browser cookie. Instead, it creates authentication cookies that contain your username, an expiry time, a session token, and a cryptographic hash. That hash proves the cookie was issued by your site and hasn't been tampered with.
Security keys and salts are the secret ingredients used to create those hashes. WordPress combines each key with its matching salt to produce a secret value, and then uses it to sign cookies and nonces. Without knowing your keys and salts, nobody can forge a valid login cookie for your site, even if they know how WordPress builds cookies.
There are four pairs, each with a specific job:
- AUTH_KEY and AUTH_SALT: Sign the authentication cookie used on non-HTTPS admin requests.
- SECURE_AUTH_KEY and SECURE_AUTH_SALT: Sign the secure authentication cookie used over HTTPS.
- LOGGED_IN_KEY and LOGGED_IN_SALT: Sign the cookie that tells WordPress you're logged in on the front end.
- NONCE_KEY and NONCE_SALT: Sign nonces, the one-time tokens that protect forms and admin actions against cross-site request forgery.
Keys and Salts Are Not Your Password
A common misunderstanding is that keys and salts are used to hash user passwords. They aren't. Passwords are hashed separately; since WordPress 6.8, core uses bcrypt for new password hashes. That means:
- Changing salts doesn't change anyone's password: Users log back in with the same password they used before.
- Changing salts doesn't revoke application passwords: If you're responding to a compromise, you need to review and revoke application passwords separately under each user's profile.
- Changing salts does invalidate every cookie and nonce: All logged-in sessions end, and any open forms or unsaved admin screens will need to be reloaded.
Why Security Keys and Salts Matter
Strong, unique keys and salts protect you in a few specific ways:
- They make cookies impossible to forge: Long random values mean attackers can't guess the secret needed to create a valid session.
- They make stolen cookies easy to kill: If someone steals a login cookie through malware or an insecure network, rotating your keys instantly makes it useless.
- They protect nonces: Unpredictable nonces are an important defence against forged requests to admin actions.
- They keep sites independent: Unique keys mean a cookie from one of your sites can't be reused on another, even if both share users.
How to Check Your Current Keys and Salts
Your keys and salts live in wp-config.php, the configuration file in your WordPress root folder. Open it through SFTP, your hosting file manager, or SSH, and look for a block like this:
define( 'AUTH_KEY', 'long random string here' );
define( 'SECURE_AUTH_KEY', 'long random string here' );
define( 'LOGGED_IN_KEY', 'long random string here' );
define( 'NONCE_KEY', 'long random string here' );
define( 'AUTH_SALT', 'long random string here' );
define( 'SECURE_AUTH_SALT', 'long random string here' );
define( 'LOGGED_IN_SALT', 'long random string here' );
define( 'NONCE_SALT', 'long random string here' );
What you find tells you what to do next:
- Eight long, random strings: You already have keys and salts. You only need to replace them if you want to rotate them.
put your unique phrase here: The installer didn't set them, which can happen with some manual installs. Replace them now.- The lines are missing entirely: Add them.
- Values that match another site you run: Replace them so each site has its own.
If the constants are missing or still set to the placeholder text, WordPress generates random fallback values and stores them in the database. That's better than nothing, but anyone who gains read access to your database also gets those secrets, and they're harder to rotate. Defining them in wp-config.php is the recommended approach.
Before making any changes, download a backup copy of wp-config.php. A typo in this file can take your whole site offline.
Method 1: Add Keys and Salts Manually
This method works on any host, as long as you can edit files.
- Generate new values: Visit the official generator at
https://api.wordpress.org/secret-key/1.1/salt/. Each time you load or refresh it, you get a brand-new set of eight random lines. - Copy all eight lines: Select everything on the page and copy it.
- Open wp-config.php: Use SFTP, your file manager, or SSH to edit the file in your WordPress root folder.
- Replace the existing block: Find the eight
define()lines for the keys and salts and replace all of them with the lines you copied. If they don't exist, paste the new lines above the comment that reads/* That's all, stop editing! Happy publishing. */. - Save the file: Upload it back to the server if you edited it locally.
- Log back in: You'll be logged out immediately. Log in again to confirm everything works.
When you paste, make sure each line keeps its opening and closing quotes and ends with );. Some random values contain characters like $, #, or backslashes, which is fine inside single quotes. Don't try to "clean up" the strings by hand.
Generate Keys From the Command Line
If you're working on a server and want to avoid copying and pasting through your browser, you can fetch a fresh set with curl and review it before adding it:
# Download a fresh set of keys and salts into a temporary file
curl -s https://api.wordpress.org/secret-key/1.1/salt/ -o /tmp/wp-salts.txt
# Review the output before using it
cat /tmp/wp-salts.txt
# Delete the temporary file when you're done
rm /tmp/wp-salts.txt
Method 2: Rotate Keys and Salts With WP-CLI
If you have SSH access and WP-CLI installed, this is the quickest and least error-prone method. Run it from your WordPress root folder:
# Replace all keys and salts in wp-config.php with new random values
wp config shuffle-salts
WP-CLI finds the eight constants in wp-config.php, generates new values, and writes them back to the file. In recent WP-CLI versions, it also adds any constants that are missing. Everyone, including you, is logged out once the command completes.
You can confirm the values changed without printing them in full by checking that the constants exist:
# Confirm the constants are defined (values are shown, so use a private terminal)
wp config get AUTH_KEY
wp config list --fields=name,type | grep -E "KEY|SALT"
Because WP-CLI edits wp-config.php directly, make sure the file is writable by the user you run the command as, and keep a backup copy beforehand.
Method 3: Use a Plugin
If you're not comfortable editing files, a plugin can rotate keys for you:
- Salt Shaker: A dedicated plugin that changes your keys and salts on demand or on a schedule, such as weekly or monthly.
- Solid Security: Includes a tool to change WordPress salts from its settings screens.
- All-In-One Security (AIOS): Offers related hardening tools, including options for forcing users to log out.
These plugins need write access to wp-config.php. On hosts where that file is read-only, or where it's been moved above the web root, they may not work, and you'll need to use one of the other methods.
Scheduled rotation logs everyone out each time it runs. For a membership site or online store, that can be annoying for customers, so choose a schedule that suits your audience, or rotate manually only when needed.
Storing Keys and Salts Outside wp-config.php
On sites deployed from Git or managed across several environments, you may not want secrets written directly in wp-config.php. A common pattern is to store them in environment variables and read them in the config file:
<?php
// In wp-config.php, above "That's all, stop editing!"
$sajjad_salt_names = array(
'AUTH_KEY',
'SECURE_AUTH_KEY',
'LOGGED_IN_KEY',
'NONCE_KEY',
'AUTH_SALT',
'SECURE_AUTH_SALT',
'LOGGED_IN_SALT',
'NONCE_SALT',
);
foreach ( $sajjad_salt_names as $sajjad_salt_name ) {
$sajjad_salt_value = getenv( $sajjad_salt_name );
if ( false === $sajjad_salt_value || '' === $sajjad_salt_value ) {
// Fail loudly rather than running with missing secrets.
header( 'HTTP/1.1 500 Internal Server Error' );
exit( 'Missing configuration.' );
}
define( $sajjad_salt_name, $sajjad_salt_value );
}
unset( $sajjad_salt_names, $sajjad_salt_name, $sajjad_salt_value );
How you set the environment variables depends on your stack. You might use your host's environment variable settings, a PHP-FPM pool configuration, or a .env file loaded by a tool like vlucas/phpdotenv in a Composer-based setup such as Bedrock. If you use a .env file, keep it outside the public web root and out of version control.
Whatever method you use, never commit real keys and salts to a public Git repository. If that has happened, rotate them immediately.
When Should You Rotate Security Keys and Salts?
Rotating your keys and salts is harmless apart from logging everyone out, so it's worth doing whenever there's a reason to end all sessions:
- After a hack or suspected compromise: This is the most important time. Rotating keys kicks out any attacker who has a stolen session cookie. Do it after you've removed malware and changed passwords.
- After a team member leaves: If someone with admin access leaves, rotating keys ends any sessions they still have open on other devices.
- After a lost or stolen device: If a laptop or phone that was logged in goes missing, rotate keys to end its sessions.
- After exposing wp-config.php: If the file was ever publicly readable, included in a public backup, or committed to Git, rotate immediately.
- When moving or cloning a site: Staging copies and clones should get their own keys so cookies aren't valid across environments.
- Periodically: Some teams rotate every few months as routine hygiene. It's optional, but it limits how long any stolen cookie could stay useful.
What to Do Alongside Rotation After a Compromise
Rotating keys alone doesn't fully secure a compromised site. If you're responding to an incident, also:
- Reset passwords for all administrator and editor accounts.
- Review users under Users > All Users and delete any accounts you don't recognise.
- Revoke application passwords in each user's profile.
- Check for malicious files, such as unknown mu-plugins or modified core files.
- Update everything to close the hole that let the attacker in.
Troubleshooting
The site shows a white screen or a PHP error after editing wp-config.php: You likely broke a quote or semicolon when pasting. Restore your backup copy, or check each define() line carefully. Turning on debug logging can help pinpoint the line.
You keep getting logged out: If a plugin is set to rotate salts on a short schedule, or another process is rewriting wp-config.php, you'll be logged out repeatedly. Check scheduled tasks and plugin settings.
The "Are you sure you want to do this?" message appears: This happens when you submit a form that was loaded before the keys changed, because its nonce is now invalid. Reload the page and try again.
Changes don't seem to apply: Make sure you edited the wp-config.php that your site actually uses. Some setups keep it one level above the WordPress folder, and WordPress checks there automatically.
FAQ: WordPress Security Keys and Salts
They're eight random secret values defined in wp-config.php that WordPress uses to sign login cookies and nonces. They make it practically impossible for anyone to forge a valid session for your site.
Yes. All existing login cookies become invalid immediately, so every user, including you, must log in again. Their passwords stay the same.
No. Passwords are hashed separately, using bcrypt in WordPress 6.8 and later. Changing keys and salts doesn't change or reset any passwords.
Use the official generator at api.wordpress.org/secret-key/1.1/salt/, run wp config shuffle-salts with WP-CLI, or use a plugin such as Salt Shaker.
Always change them after a hack, a staff departure, a lost device, or any exposure of wp-config.php. Routine rotation every few months is optional but reasonable.
WordPress generates fallback values and stores them in the database. That works, but defining unique values in wp-config.php is more secure and easier to rotate.
No. Give each environment its own keys and salts so a cookie from one site can never be accepted by another.
Conclusion
Security keys and salts are eight lines in wp-config.php that quietly protect every login session and nonce on your WordPress site. Adding them is simple: generate a fresh set from the official WordPress.org generator and paste them in, run wp config shuffle-salts with WP-CLI, or let a plugin like Salt Shaker handle it. Just take a backup of wp-config.php first and be ready to log in again.
Once they're in place, think of rotating them as your emergency "log everyone out" button. Use it after a compromise, a team change, or a lost device, and pair it with password resets and a review of application passwords when the situation calls for it. It's one of the easiest security steps in WordPress, and one of the most effective when you need it.


