How to Regenerate WordPress Security Keys and Salts (and What Breaks)

This article is a localized edition of the Japanese original. Read the Japanese original

WordPress's wp-config.php contains eight values called authentication keys and salts. The cookies that keep users logged in and nonces (values that protect forms against forged requests) are built from these values. When you replace them, every login cookie issued so far stops working, and all users, administrators included, are logged out.

This article explains how to regenerate the keys and salts and what to know before you do it. The WP-CLI commands and WordPress behavior were checked against the official documentation and source code as of November 2026.

What the keys and salts do

These eight constants are defined in wp-config.php:

The comment in wp-config-sample.php also says you can change these at any time, and that doing so invalidates all existing cookies and forces all users to log in again.

When regenerating makes sense

• You suspect an unauthorized login or a stolen cookie and want to cut off the attacker's session
• The contents of wp-config.php may have leaked (pushed to a public repository, a backup file left in a public directory, and so on)
• The values are still the initial put your unique phrase here
• The site was built by copying wp-config.php from another site and still uses the same values as the original

As for rotating them on a schedule, there are side effects (described below), so doing it when you have a reason like those above is enough.

Check the current state

If you can use WP-CLI, check from the WordPress directory as follows. Don't print the values themselves; only check that they are defined and how long they are.

# Are the eight constants defined?
wp config has AUTH_KEY && echo "AUTH_KEY: defined"

# Is the initial value still there? (no output means it is not)
grep -n "put your unique phrase here" wp-config.php

# Length of the value (character count including the newline)
wp config get AUTH_KEY | wc -c

Even if the constants are left at the initial value or not defined, WordPress generates random values instead, stores them in the database (options such as auth_key) and uses those. Those values, however, don't change when you edit wp-config.php. Defining unique values in wp-config.php is easier to manage and keeps regeneration simple.

Method 1: Regenerate with WP-CLI

The quickest way is WP-CLI's wp config shuffle-salts. It fetches new values from the official WordPress.org API and rewrites the eight constants in wp-config.php.

# Keep a copy of wp-config.php before you start
cp -p wp-config.php wp-config.php.bak-$(date +%Y%m%d)

# Replace all eight keys and salts with new values
wp config shuffle-salts
# Success: Shuffled the salt keys.

You can also change only specific constants:

# Change only the values used for login cookies
wp config shuffle-salts AUTH_KEY AUTH_SALT SECURE_AUTH_KEY SECURE_AUTH_SALT LOGGED_IN_KEY LOGGED_IN_SALT

Because the command rewrites wp-config.php, run it as the file's owner (for example the web server user). Running it as root can change the file's owner, so specify the owner, as in sudo -u www-data wp config shuffle-salts (www-data is the example for Apache or Nginx on Debian / Ubuntu).

After running it, reload the admin screen in your browser and you'll be sent back to the login screen. Confirm that you can log in again and that the site displays normally.

Method 2: Edit the file by hand

Where WP-CLI isn't available, create new values with the WordPress.org generator and paste them into wp-config.php.

1. Open https://api.wordpress.org/secret-key/1.1/salt/ in your browser. Each time you open it, it shows eight define lines with random values.
2. Download wp-config.php via FTP or your server's file manager and keep a copy.
3. In wp-config.php, replace the eight lines from AUTH_KEY to NONCE_SALT with the eight lines shown.

After the replacement it looks like this (the values are placeholders; use the generated ones):

<?php
define( 'AUTH_KEY',         'generated 64-character random value' );
define( 'SECURE_AUTH_KEY',  'generated 64-character random value' );
define( 'LOGGED_IN_KEY',    'generated 64-character random value' );
define( 'NONCE_KEY',        'generated 64-character random value' );
define( 'AUTH_SALT',        'generated 64-character random value' );
define( 'SECURE_AUTH_SALT', 'generated 64-character random value' );
define( 'LOGGED_IN_SALT',   'generated 64-character random value' );
define( 'NONCE_SALT',       'generated 64-character random value' );

1. Save and upload the file, then confirm you can log in to the admin screen again.

Defining the same constant twice triggers a PHP warning, so delete the old eight lines before pasting. The generated values contain many symbols; don't retype them, copy all eight lines at once.

Clear the login sessions too

Changing the keys makes login cookies unusable, but each user's session records (the session_tokens user meta) remain in the database. If you want to clear those records too, delete every user's sessions with WP-CLI:

# Delete the sessions of all users
wp user list --field=ID | xargs -n 1 wp user session destroy --all

For a single user, specify the username, as in wp user session destroy admin --all. In the admin screen, "Log Out Everywhere Else" on each user's profile screen also ends that user's other sessions.

Access that regeneration does not stop

Regenerating the keys and salts only invalidates cookie-based logins. If you are doing it in response to unauthorized access, also check the following:

• Passwords: If the attacker knows a password, they can simply log in again. Change passwords, administrators included.
• Application passwords: Application passwords used for the REST API and similar don't rely on cookies, so they stay valid after the keys change. List them with wp user application-password list 1 (1 is the user ID) and revoke any you don't recognize in the Application Passwords section of the profile screen.
• Unknown administrator accounts: Check with wp user list --role=administrator.
• Tampered files: If a backdoor was planted in a plugin or theme, the attacker can get back in even after the keys change. Compare WordPress core files with wp core verify-checksums, and plugins distributed on wordpress.org with wp plugin verify-checksums --all, against the originals.

What regeneration affects

• All logged-in users: Administrators, editors, members of a membership site and so on are all logged out at once. Do it when nobody is in the middle of work.
• Online store carts: WooCommerce ties a guest's cart to a session cookie. The salts are also used to verify that cookie, so carts may be emptied after regeneration.
• Plugins that use the keys for encryption: Some plugins use these values to encrypt the data they store. For example, Site Kit by Google uses LOGGED_IN_KEY and LOGGED_IN_SALT by default to encrypt its Google connection data, so changing them breaks the connection and you have to reconnect. For Site Kit, define GOOGLESITEKIT_ENCRYPTION_KEY and GOOGLESITEKIT_ENCRYPTION_SALT in wp-config.php before regenerating, set to the current LOGGED_IN_KEY and LOGGED_IN_SALT values, and the connection is kept (these two values must never be changed once set).

If you want to rotate them regularly

If your policy is to rotate them regularly, run WP-CLI from the server's cron rather than from a WordPress plugin or theme. Set it up only after confirming the effects above (everyone logged out, carts, plugins that encrypt with the keys).

# Example /etc/cron.d/wp-shuffle-salts
# Run at 3:00 a.m. on the 1st of every month as the file owner (www-data)
0 3 1 * * www-data /usr/local/bin/wp --path=/var/www/html config shuffle-salts --quiet

Adjust the path to wp and the WordPress path to your environment. On shared hosting, register the same command in the cron settings of the hosting company's control panel.

Summary

• Changing the authentication keys and salts invalidates all existing login cookies and logs out every user.
• With WP-CLI, use wp config shuffle-salts; by hand, replace the eight lines with values from https://api.wordpress.org/secret-key/1.1/salt/. Keep a copy of wp-config.php before you start.
• When responding to unauthorized access, also check passwords, application passwords, administrator accounts and tampered files.
• Check the impact on features that depend on the salts, such as WooCommerce carts and Site Kit, before you run it.

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)