How to change WordPress salts and security keys

Prepare a reliable way back into the dashboard

This change deliberately interrupts signed-in sessions, including your own. Before working on the configuration, make sure you can sign back in without relying on a browser tab that is already open. Keeping hosting access available gives you a separate recovery route if a typing error prevents WordPress from loading.

Know what changing the keys does

Keys and salts are secret random values used when WordPress checks login cookies and certain security tokens. They belong to the site configuration, not the account password field. Changing them does not delete users, alter published pages or assign new account passwords.

If you suspect a compromise, rotating these values is one part of recovery. An attacker with a working password or a remaining malicious file can regain access. Follow the malware recovery guidance and review accounts before treating a successful logout as proof of safety.

1. Prepare for everyone to sign in again

Ask editors to save their work and choose a quiet period. Open forms and administrator actions can carry old security tokens and need reloading afterwards. Confirm you know your WordPress password and can use your two-factor method or recovery codes. If needed, recover the account before starting.

Sign in to hosting File Manager and locate wp-config.php for this installation. It is beside the WordPress folders in a standard setup, but the host can store it elsewhere. Download an untouched copy to a private folder on your computer and keep File Manager open.

Do not save a renamed copy in the public website directory. Both old and new versions contain secrets. If the file reads keys from environment variables or a hosting service, ask the provider to rotate them through that system instead of adding a second configuration source.

The Profile screen is available from Users in this earlier WordPress interface. Use it for account preparation if you need to update your password; site-wide keys belong in the configuration file, not this menu. Credit: WordPress Training Team / Learn WordPress, CC BY-SA 4.0.

2. Generate fresh values from WordPress.org

Open the official WordPress key and salt generator in your browser. It displays eight PHP definition lines containing fresh random strings. Copy the entire block, including the surrounding quotes and semicolons.

Use the generated block privately for this site only. Do not copy example keys from an article, make up memorable phrases or paste the block into a support message. There is no need to execute it in a terminal or the browser console.

3. Replace the existing block without adding duplicates

In File Manager's text editor, find the Authentication Unique Keys and Salts section. Locate all eight existing definitions with these names:

The four keys: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY and NONCE_KEY.
Their matching salts: AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT and NONCE_SALT.

4. Save and verify the old login no longer works

Save the file and open the public homepage. Then refresh a dashboard tab that was signed in before the change. WordPress should request authentication again. Sign in with the same account password and two-factor method, then open a draft to check normal editing.

If the site produces a syntax error after saving, restore the untouched configuration through File Manager. That returns the previous keys too, so the intended rotation is not complete. Have the edit checked and repeat it with a fresh block once the cause is understood.

An old dashboard session that still works needs another check: confirm you edited the configuration used by this site and did not leave duplicate definitions or a hosting override. Ask support to inspect the active configuration without sending the secret strings. A restored public page alone does not prove the new values were loaded.

5. Review the credentials outside this change

Reload forms that were open before the change and test relevant customer sign-in or checkout behaviour. Plugins can use these values in their own session handling, so check customer carts as well.

WordPress application passwords and third-party API keys are separate credentials. Review and revoke them through their own account settings if required; do not assume rotating salts revoked every integration. For a security incident, also review administrator accounts, reset exposed credentials and enable two-factor authentication.

Record the date and purpose of the rotation without recording the actual keys. Remove temporary copies from shared clipboards or documents and retain any necessary recovery file only in protected storage.

Official references

WordPress lists the configuration file's authentication keys and salts and explains how security tokens use the nonce key and salt.

Get help with the next step

If keys were exposed or the site has signs of unauthorised access, ask BugShield to review the wider incident. Replacing the block is useful, but the cause of the exposure still needs to be addressed.

Questions answered

How to change WordPress salts and security keys FAQs

Will everyone need a new password?

Changing keys invalidates existing WordPress login cookies but does not change account passwords. Reset a password separately if it was exposed or no longer belongs to an authorised person.

Does this encrypt the WordPress database?

No. These values support authentication and security-token checks. Database encryption and backup protection are separate controls.

Should I use the same keys on every site?

Generate a fresh set for each site. Reusing the same values unnecessarily connects the impact of one configuration exposure to other installations.

Does salt rotation revoke application passwords?

Do not rely on it for that purpose. Application passwords and other service credentials need review and revocation through their own account controls.

What if my host manages the keys outside wp-config.php?

Use the provider's documented rotation mechanism. Adding duplicate definitions to the file can conflict with the managed configuration and fail to change the effective values.

Keep troubleshooting