How to Change WordPress Security Keys and Salts

To change WordPress security keys and salts, replace the eight values in wp-config.php, from AUTH_KEY through NONCE_SALT, with new random strings, then save the file. You can generate them with a salt generator or run wp config shuffle-salts in WP-CLI. Every logged-in user, including you, is logged out and must sign in again. Passwords, content and settings are not affected. It is a quick, safe step after a suspected break-in, a staff change or a leaked config file. On its own, though, it does not remove an attacker.

This post explains what the keys and salts do and when to change them. It covers three ways to change them, including how to check that the change took effect. We tested the process on a WordPress 7.1.3 test site: what logged out, what kept working, and one delay caused by PHP's code cache that can make it look as if nothing happened.

What the keys and salts do

The default wp-config.php file has eight constants:

Table: WordPress security keys and salts

Key	Salt	Used for
AUTH_KEY	AUTH_SALT	The login cookie on HTTP connections
SECURE_AUTH_KEY	SECURE_AUTH_SALT	The login cookie on HTTPS connections
LOGGED_IN_KEY	LOGGED_IN_SALT	The cookie that marks a visitor as logged in on the front end
NONCE_KEY	NONCE_SALT	Nonces: the one-time tokens that protect forms and admin links

WordPress combines each key and salt into a secret that it uses to sign these cookies and tokens. Anyone who knows the secrets could, in principle, forge a valid login cookie. Changing the secrets makes every existing cookie and nonce invalid at once.

The keys and salts do not protect stored passwords. In current WordPress, password hashing uses bcrypt with a fixed pre-hashing key, independent of these constants. That is why changing them does not change or reset anyone's password.

What if the placeholders were never replaced?

If a constant is missing, still set to put your unique phrase here, or duplicated, WordPress does not use the weak value. Its wp_salt() function generates a random value and stores it in the database instead. We confirmed this on the test site: setting AUTH_KEY to the placeholder made WordPress create a 64-character auth_key option. So the site is not wide open, but the secret now lives in the database, where a database leak would expose it. Set proper values in wp-config.php.

<h2

When to change them

• After a suspected compromise, as one of several clean-up steps.
• When someone with admin or server access leaves, such as a former employee or agency.
• If wp-config.php may have been exposed: committed to a public Git repository, shared in a support ticket, backed up to an insecure location or readable because of a server misconfiguration.
• After migrating from a site you did not set up, or cloning a site from a template that shipped with fixed values.
• If they are still placeholders or identical to another site's.

There is no official schedule for routine rotation. Some administrators change them once or twice a year as housekeeping; the only cost is logging everyone out.

Before you start

• Download a copy of wp-config.php so you can restore it if you make a typing mistake.
• Warn your users on a membership or shop site: everyone will be logged out, and customers may lose items in their basket if the basket is tied to a login.
• Save any open work in the editor. Open editing screens will fail to save after the change, because their nonces become invalid.
• Know how you will edit the file: SFTP, your host's file manager or WP-CLI.

<h2

Method 1: replace the values by hand

• Generate eight new values with the WordPress salt generator. It creates all eight in your browser using a cryptographic random generator and avoids quotes and backslashes that would break the PHP.
• Open wp-config.php and find the block that starts with define( 'AUTH_KEY'.
• Replace the whole block of eight lines with the new block. Do not leave old lines behind: if a constant is defined twice, PHP keeps the first value and shows a warning.
• Save and upload the file.
• Reload the dashboard. You should be sent to the login screen.

The new block looks like this. These values are illustrative; never copy salts from an article.

define( 'AUTH_KEY',         'replace-with-64-random-characters' );
define( 'SECURE_AUTH_KEY',  'replace-with-64-random-characters' );
define( 'LOGGED_IN_KEY',    'replace-with-64-random-characters' );
define( 'NONCE_KEY',        'replace-with-64-random-characters' );
define( 'AUTH_SALT',        'replace-with-64-random-characters' );
define( 'SECURE_AUTH_SALT', 'replace-with-64-random-characters' );
define( 'LOGGED_IN_SALT',   'replace-with-64-random-characters' );
define( 'NONCE_SALT',       'replace-with-64-random-characters' );

WordPress.org also provides a generator at https://api.wordpress.org/secret-key/1.1/salt/, which returns a ready-made block of eight lines.

Method 2: WP-CLI

If you have SSH access with WP-CLI installed, one command replaces all eight values:

wp config shuffle-salts

On our test site (WP-CLI 2.12.0), it replaced all eight values in place and reported "Success: Shuffled the salt keys." You can also pass specific key names to change only some of them, but for a security response change them all.

Method 3: a new wp-config.php

When you set up a new site or rebuild a config file, the wp-config.php generator includes eight freshly generated keys and salts in the file it builds. Our guide to wp-config.php settings explains the rest of the file.

Worked example: what changed on our test site

We logged in as an administrator, created an application password, created a nonce, then ran wp config shuffle-salts. These results are from that WordPress 7.1.3 test site:

Table: Effects of changing the salts (tested)

Item	Before	After
Dashboard with the existing login cookie	Loaded (200)	Redirected to the login screen with reauth=1 (302)
Logging in again with the same password	N/A	Worked
Nonce created before the change	Valid	Invalid
REST API request with an application password	Worked (200)	Still worked (200)
Session records stored for the user	1	Still 1 (stored, but no longer usable with old cookies)

Two results deserve attention.

Application passwords survive. They are checked against their own stored hashes, not against cookies, so changing salts does not revoke them. After a compromise, also review Users → Profile → Application Passwords for every administrator and revoke anything you do not recognise.

There can be a short delay. In our first attempt, the old cookie still worked immediately after the file changed and stopped working a few seconds later. Our test server had PHP's OPcache enabled with a revalidation interval of 2 seconds, so it kept running the old compiled copy of wp-config.php briefly. On hosts where OPcache is set never to recheck files, the old salts can stay in use until PHP is restarted or the cache is cleared. If logging out does not happen, clear OPcache from your host's control panel or restart PHP.

A complete clean-up after a suspected compromise

Changing salts ends existing sessions, but it does not remove an attacker who has another way in. Combine it with:

• Changing passwords for all administrator accounts, the database user, hosting, SFTP and email accounts linked to the site.
• Reviewing user accounts and removing any administrators you do not recognise.
• Revoking unknown application passwords.
• Updating WordPress, plugins and themes, and removing anything unused.
• Scanning files for changes and restoring from a clean backup if needed.
• Changing the keys and salts last, so any sessions an attacker opened during the clean-up are also ended.

Strong new passwords can come from the password generator.

Planning a routine rotation

If you decide to rotate the keys on a schedule rather than only in an emergency, make it a short, predictable task:

• Pick a quiet time. Choose the hour with the fewest logged-in users, which is usually visible in your analytics or shop reports.
• Tell people who log in. A one-line notice to editors, or a banner for members, avoids support requests about being logged out.
• Back up wp-config.php and keep the copy somewhere private, not in the web root.
• Rotate on staging first if you have custom login integrations, single sign-on or a membership plugin, to confirm nothing depends on the old values.
• Rotate on live with the generator or WP-CLI, then clear OPcache if your host offers a button for it.
• Log the date in your maintenance notes so the next person knows when it was last done.

Keep the keys out of version control. If your site's configuration is in Git, load the secrets from environment variables or a file that is excluded from the repository, and rotate them immediately if they were ever committed.

Verify the change

• Reload the dashboard in a browser where you were logged in. You should be asked to log in again.
• Open wp-config.php and confirm each of the eight constants appears exactly once.
• Check the site's front end and dashboard load without PHP errors.
• If you use WP-CLI, run wp config get AUTH_KEY to confirm the new value is in place.
• Confirm wp-config.php cannot be downloaded: requesting it in a browser should show a blank page or an error, never the file's contents. Our .htaccess guide includes a rule that denies direct access.

Common mistakes

• Pasting the new block without deleting the old one, so the old values are still the ones used.
• Breaking the file with an unescaped quote or a missing semicolon.
• Copying example values from a tutorial instead of generating new ones.
• Expecting the change to reset passwords or remove attackers.
• Forgetting application passwords during a security clean-up.
• Rotating salts in the middle of a busy shop's trading day without warning customers.
• Changing salts on a staging copy and assuming the live site is done too; each site has its own file.

Troubleshooting

Table: Salt change problems and fixes

Symptom	Likely cause	Fix
Nobody was logged out	Old block still above the new one, wrong file edited, or OPcache serving the old file	Remove duplicates; check the file path; clear OPcache or restart PHP
White screen or "critical error"	Syntax error in the new lines	Restore your backup and paste the block again from the generator
Warning "Constant AUTH_KEY already defined"	A key is defined twice	Delete the duplicate line
Editor shows "The link you followed has expired"	The page was open before the change, so its nonce is invalid	Reload the page and try again
Integration still has access	It uses an application password or API key	Revoke and reissue its credentials
Login loop after the change	Cached login page or stale cookies	Clear browser cookies for the site and purge the page cache

Frequently asked questions

What are WordPress salts?

They are eight random secrets in wp-config.php that WordPress uses to sign login cookies and nonces. Four are called keys and four are called salts; WordPress combines each pair.

Is it safe to change WordPress salts?

Yes. The only visible effect is that everyone is logged out and open forms need reloading. Passwords, content and settings are unaffected.

Will changing salts reset user passwords?

No. Password hashes do not depend on the keys and salts. In our test, the administrator logged in again with the same password straight away.

How often should I change the salts?

There is no required schedule. Change them after a suspected compromise, when someone with admin access leaves, or if the config file may have been exposed.

Does changing salts log out application passwords?

No. In our test, a REST API request with an application password still worked afterwards. Revoke application passwords separately if needed.

Why wasn't I logged out after changing them?

Usually the old lines are still in the file, or PHP's OPcache is still running the old version. Remove duplicates, then clear OPcache or restart PHP.

What happens if I leave the default placeholder text?

WordPress ignores the placeholder and stores random values in the database instead. That works, but proper values in wp-config.php keep the secrets out of the database.

Can I change only one key?

Yes; WP-CLI accepts specific key names. Changing one invalidates whatever it signs. For a security response, change all eight.

Do multisite networks need one set per site?

No. A multisite network shares one wp-config.php, so one set of keys and salts covers the whole network, and changing them logs out users on every site.

Is a salt generator safe to use?

Use one that generates values in your browser with a cryptographic random generator, or WP-CLI, so the values are not sent anywhere or reused.

Next step

Generate a fresh set with the WordPress salt generator, replace the eight lines in wp-config.php, and confirm you are asked to log in again.