Site security guide

WordPress keys and salts: what to rotate, and when.

The eight secrets in wp-config.php help protect authentication cookies and nonces. Replace them deliberately, not reflexively.

5 min readUpdated 26 July 2026wp-config.php reference

Four keys

  • AUTH_KEY
  • SECURE_AUTH_KEY
  • LOGGED_IN_KEY
  • NONCE_KEY

Four salts

  • AUTH_SALT
  • SECURE_AUTH_SALT
  • LOGGED_IN_SALT
  • NONCE_SALT

These values are installation-specific secrets. WordPress combines them with authentication data to make cookies and nonces difficult to forge or reuse elsewhere.

What changes when you rotate them?

Replacing the values invalidates existing authentication cookies. In practice, everyone currently signed in—including you—will need to sign in again. The database, posts, media, and account passwords are not changed; it is a session reset, not a password reset. This trips people up often enough that it has its own myth-busting section in the migration guide — rotating salts is one of the few things people mistake for a password change when it categorically is not.

That makes rotation useful after a suspected compromise, after secrets appeared in a repository or backup, or when you deliberately need to force a global sign-out. It also means rotation should be coordinated on an active site so administrators and users know why they were logged out.

What each key protects

The four keys and four salts exist in matched pairs, one pair per purpose. Replacing all eight together is always safe; there is no benefit to rotating only some of them.

AUTH_KEY / AUTH_SALTSigns the main authentication cookie used to recognize a logged-in browser.
SECURE_AUTH_KEY / SALTSigns the equivalent cookie when the site is served over HTTPS.
LOGGED_IN_KEY / SALTSigns the cookie WordPress checks on every page, including the public site, not only wp-admin.
NONCE_KEY / SALTAdds entropy to the one-time tokens (nonces) that protect forms and AJAX requests from forgery.

A leaked AUTH_KEY/AUTH_SALT pair is what would let an attacker forge a valid-looking session cookie without ever knowing a password — which is why they belong in the same "treat as a secret" category as the database password, not as configuration trivia.

Rotate now

  • A secret was committed to a public repository.
  • You suspect server, backup, or credential exposure.
  • You need to invalidate all active sessions.
  • You inherited a site with known placeholder values.

Usually wait

  • Nothing has been exposed and no session reset is needed.
  • You are rotating solely because a calendar reminder fired.
  • The site is in a sensitive maintenance window.
  • You cannot coordinate the expected global sign-out.

How to replace the values safely

  1. 01
    Back up wp-config.php.

    Keep a private, recoverable copy before editing the configuration. Do not put that backup in a public project or support ticket.

  2. 02
    Generate a complete set.

    Use the local generator to create all eight definitions. Generate once, copy once, and keep the result private.

  3. 03
    Replace the existing block.

    In wp-config.php, replace the eight matching define() lines from AUTH_KEY through NONCE_SALT. Do not duplicate a constant or leave half the old set in place.

  4. 04
    Save and test.

    Load the site, sign in again, and confirm any integrations that depend on authenticated sessions behave as expected.

WP-CLI alternative

When you have authorized shell access and WP-CLI is installed, wp config shuffle-salts can refresh the standard values in the configuration file. It is still a production change: make a backup, use the correct site directory, and expect every active session to end.

Manual rotation vs. a security plugin

Several security plugins offer a one-click "regenerate salts" button. That is a legitimate option and does exactly what manual rotation does under the hood — it still forces a global sign-out and still leaves passwords untouched. The trade-offs run the other way: a plugin adds one more piece of software with write access to wp-config.php, and its randomness quality is only as good as its implementation. Generating locally, as this guide describes, keeps the number of things that touch your secrets to a minimum and lets you verify exactly what was written.

Either approach is fine for a routine rotation. For a suspected compromise, prefer whichever method you can execute fastest without introducing a new unknown into an already uncertain situation.

Keep the new values safe

  1. Keep wp-config.php outside version control, or use an encrypted secret-management workflow.
  2. Remove exposed keys from public history and backups where your retention process allows it.
  3. Do not send the generated values in chat, email, screenshots, or support tickets.
  4. Record that a session reset occurred, without recording the secret values themselves.

Quick answers

Does rotating salts change any passwords?

No. Salts and keys sign session cookies and nonces, not passwords — the password hashes in wp_users are completely untouched by a salt rotation. Anyone locked out after a rotation is experiencing the expected logout, not a password change.

How often should WordPress salts be rotated?

There's no schedule WordPress enforces. A reasonable baseline many sites use is roughly every 90 days, plus an immediate rotation after any suspected compromise, admin offboarding, or hosting migration — a routine calendar-driven rotation without one of those triggers is a defensible but genuinely optional habit.

What happens if I only replace some of the eight values?

The rotated ones stop matching old cookies (which is what you want) while the untouched ones keep signing with the old secret. There's no security benefit to a partial rotation over a full one, and it's easy to lose track of which pair is stale — replace all eight together.

Can I rotate salts while also touching other wp-config.php settings?

Yes — they're independent constants. If you're already editing wp-config.php for an HTTPS or proxy setting, see the HTTPS redirect loop guide before changing anything TLS-related, since that's a common way to introduce a second, unrelated outage in the same edit.

Primary reference: WordPress wp-config.php documentation and WP-CLI shuffle-salts.