WordPress Security Keys & Salts: Setup, Rotation, Fixes

You open wp-config.php, scroll past the database settings, and hit a block of eight lines that look like someone smashed a keyboard: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, and their _SALT twins. Most site owners never touch them — until everyone gets logged out at once, or a security scanner flags them as weak, and suddenly you need to know what these actually do.

What security keys and salts actually do

These eight constants aren't decoration. WordPress uses them to encrypt the authentication cookies and nonces your browser stores after you log in. When you log into wp-admin, WordPress doesn't just remember "user #1 is logged in" — it generates a cookie that's cryptographically signed using these keys. Every request after that, WordPress re-checks the signature. If the keys change, every existing signature instantly becomes invalid.

The four _KEY constants and four _SALT constants exist as separate pairs because WordPress uses them for different cookie types — regular auth, secure (HTTPS-only) auth, the logged-in state, and nonces (the one-time tokens behind "Are you sure you want to do this?" checks). Splitting them means a leak in one doesn't automatically compromise the others.

If you've ever opened wp-config-sample.php on a fresh install, you've seen the placeholder:

define( 'AUTH_KEY',         'put your unique phrase here' );
define( 'SECURE_AUTH_KEY',  'put your unique phrase here' );
define( 'LOGGED_IN_KEY',    'put your unique phrase here' );
define( 'NONCE_KEY',        'put your unique phrase here' );
define( 'AUTH_SALT',        'put your unique phrase here' );
define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );
define( 'LOGGED_IN_SALT',   'put your unique phrase here' );
define( 'NONCE_SALT',       'put your unique phrase here' );

Softaculous and most one-click installers replace these with random values automatically, so you rarely see the placeholder text on a live site. But plenty of sites get migrated, cloned, or hand-built, and the sample text survives the trip.

Symptom: what you'll actually notice

Nobody searches for "my security keys are wrong." You notice one of these instead:

• You get logged out of wp-admin randomly, sometimes mid-edit, with no session-timeout setting to explain it.
• After a migration or restore, every logged-in user — including you — gets kicked out at once.
• A security plugin (Wordfence, iThemes Security, Sucuri) flags "weak or default security keys detected."
• On a multisite network, users on one subsite get logged out when switching to another.
• "Are you sure you want to do this?" nonce errors appear on forms that worked fine yesterday.

Cause: why this happens

1. The keys were never set (placeholder text left in place)

If wp-config.php still has literal text like put your unique phrase here, WordPress still works — but every visitor's cookie is signed with the same predictable string. That's the "weak keys" warning your security plugin is catching. It's a real, if minor, attack-surface reduction issue: predictable keys make cookie forgery marginally easier for anyone who's already found another way onto your server.

2. Keys changed during a migration

When you move a site — Duplicator, manual file copy, a fresh Softaculous install pointed at an old database — the new wp-config.php usually gets a freshly generated set of keys, but the database still has old sessions signed with the previous ones. Result: instant mass logout. This is expected and harmless, just disruptive if you don't warn your team first.

3. You regenerated them on purpose (or a security plugin did)

Rotating keys is a legitimate incident-response step. If a site was compromised — or you suspect a leaked admin cookie, a shared/former-employee session, or a plugin vulnerability that touched auth — regenerating the keys invalidates every active session network-wide. That's the whole point: it's a kill switch for sessions you can't otherwise revoke individually.

4. Multisite cookie domain mismatch

On a multisite network using subdomains, a missing or inconsistent COOKIE_DOMAIN alongside the keys can cause the same symptom — logins that don't persist across subsites. It looks identical to a key problem but the fix is different (see below).

Fix: rotate the keys correctly

Never hand-type random characters into these fields. WordPress.org runs a generator that produces cryptographically random values in the exact format needed:

1. Open https://api.wordpress.org/secret-key/1.1/salt/ in a browser. It returns eight ready-to-paste define() lines.
2. In cPanel, open File Manager → navigate to public_html (or your site's folder) → edit wp-config.php. On a VPS, use nano, vim, or SFTP.
3. Find the block between /**#@+ Authentication Unique Keys and Salts. */ and /**#@-*/, delete the old eight lines, and paste the new ones in their place.
4. Save the file. No database change, no cache clear, no restart needed — the new keys apply on the very next request.

Every logged-in user, including you, will be signed out immediately. If it's a live store or membership site, do this in a quiet window and give staff a heads-up — customers mid-checkout won't be affected (cart sessions aren't tied to these keys), but anyone logged into an account will need to log back in.

Via WP-CLI, if you have SSH access on a VPS:

wp config shuffle-salts

This pulls fresh values from the same WordPress.org API and writes them directly, which is faster than the copy-paste route if you're already at a terminal.

If the problem is actually multisite cookies, not the keys

Check COOKIE_DOMAIN in wp-config.php. For a subdomain multisite network it should either be absent (WordPress auto-detects it correctly in most setups) or explicitly set to your root domain, not a specific subsite:

define( 'COOKIE_DOMAIN', '' ); // let WordPress detect it, usually the safest default

Rotating the security keys won't fix a cookie-domain mismatch, and a cookie-domain fix won't fix genuinely weak keys — diagnose which one you actually have before changing anything, or you'll log everyone out twice for nothing.

Prevention

A word on caching

If your site uses a persistent object cache (Redis, Memcached) or an aggressive page cache, clear it after rotating keys. Some caching layers store the previous auth state and can serve a stale "still logged in" page for a few minutes even after the keys change — confusing, but harmless, and a cache flush clears it immediately.