WordPress Salts Explained: Update Security Keys in wp-config

Your admin cookie gets grabbed. Whoever holds it is inside `wp-admin` right now — sliding between customer accounts, peeking at order data, possibly swapping checkout redirects. While you scramble to reset passwords, that attacker is moving through your store with a session valid until it expires. There is a faster reset sitting one file away, and most store owners have never touched it.

WordPress security salts are cryptographic strings stored in `wp-config.php` that fingerprint every authenticated cookie your site issues. Rotate them and WordPress treats every existing cookie as forged. The hijacker loses access in the same second you hit save. No password-reset races, no plugin juggling — just four constants swapped out and the threat drops to zero session authority.

If a stolen cookie is the keys to your store, rotating salts is the locksmith who re-pins every lock before the thief reaches the next door.

What Salts Actually Do in Your Authentication Stack

When a user logs in, WordPress mashes a few pieces of information together — username, expiration timestamp, the user's role — and signs the result using a secret string. The browser stores the signed bundle as a cookie. On every subsequent request, WordPress recomputes the signature using the same secret string and compares. If the math matches, the user is trusted. If the attacker doesn't know the secret string, forging a cookie is computationally out of reach.

That secret-string family lives in `wp-config.php` under four constants, and each one handles a different trust boundary. Forget the academic framing — what matters for your store is that these strings are the difference between "anyone with a stolen cookie can browse `wp-admin`" and "they can't, even with the original cookie in hand." The longer and more random the strings, the more brute-force attempts have to run to guess them. WordPress's official generator produces 64-character hashes full of entropy, which is why the math is so unforgiving.

If `wp-config.php` itself is compromised — read by someone who shouldn't have it — the salts go with it. An attacker who sees your salts can forge cookies that WordPress will accept as genuine. The reverse situation, rotating salts on an already-leaked file without cleaning up the leak, doesn't close the hole. Salts are a session defense, not a file-leak defense, and they don't replace strong passwords, two-factor authentication, or hardened file permissions.

The Four Constants Buried in wp-config.php

Open your root directory, find `wp-config.php`, and scroll down past the database credentials. You'll hit a block that looks like a polite password riot. Each line is one cookie flavor WordPress issues. Here's how to read them like a store owner, not a cryptographer.

Skip the deep theory if you're chasing only the practical answer: any attacker who reads all four has full session-forgery power. Any single leak only weakens the boundary that one constant protects. Rotate all four together. Partial rotation leaves an asymmetric trust state where some cookies still validate and others don't, which is a debugging headache you don't want during a live incident.

How to Rotate Your Security Keys Without Losing the Store

Numbered steps, with branching for the way your hosting actually works.

1. Generate fresh keys. Pull eight new strings (four keys plus four matching salts, although most installations reference only the keys now) from the WordPress secret-key service. Don't write them yourself — manually-typed strings are predictable, and predictable defeats the whole point.

2. Pull `wp-config.php` from the server. SFTP in or use your host's file manager. Always work off a local backup. If your host locks the file to permissions 444 or 440, drop it to 644 temporarily, edit, then restore the tighter permissions.

3. Replace the four blocks. Find `AUTH_KEY`, `SECURE_AUTH_KEY`, `LOGGED_IN_KEY`, `NONCE_KEY`. Drop each generated string into its `define('X', 'long-random-string-here');` line. Don't reorder. Don't combine lines. Constant names must stay identical — only the values change.

4. Save and push back. Re-upload, restore permissions to 440 (or whatever your hardening standard calls for). Reload the file once to confirm the parse succeeded and the site didn't white-screen.

5. Test the front end as a logged-out visitor, then as a logged-in customer. If the second test logs you out the instant you refresh, the rotation worked. That's the desired behavior during an incident — mildly annoying during a routine refresh, deliberate during a breach.

6. Flush object cache and CDN cache if your stack uses one. Most `wp-admin` and cookie-related responses don't sit in object cache, but a stale browser tab holding the old nonce behavior can spook editors into thinking they're broken.

If your host runs a managed WordPress install that hides `wp-config.php` behind a custom panel, then look for a "secret keys" or "security keys" field there — same outcome, same four constants, no SFTP required. If you can't edit the file directly but you have database access, then check whether a hardening plugin like Wordfence or a host-side tool exposes a rotation button that injects the new values via an override. If none of those routes exist, then it's a host-escalation conversation, because a locked `wp-config.php` you can't rotate is a locked door in an emergency.

The Instant Effect: Every Session Dies at Once

Rotation is not a soft reset. It's a clean cut. Every authenticated browser session on your site — yours, your customers, your editors, your fulfillment lead, that suspicious bot account you never got around to closing — loses its verification the moment the new keys hit disk. On a 10,000-visitor store with, say, several hundred logged-in shoppers mid-checkout, that's several hundred carts that suddenly look anonymous again. None of those customers were compromised by the rotation itself; they're fine and will simply re-authenticate.

The business case for understanding this is sharp: if you rotate during peak traffic, expect a wave of cart abandonment not because of fraud but because of friction. A returning customer trying to buy, getting bounced to the login screen, deciding the cart isn't worth re-entering credentials for — that is checkout friction in its purest form. The operator move is to time routine maintenance to low-traffic windows, and refuse to compromise when you suspect an active breach. A day's worth of re-auth friction is cheaper than a quarter's worth of leaked customer data.

Salt rotation invalidates 100% of cookies on every device, in every browser, for every role. Plan for that — or rotate reactively and own the fallout.

Some plugins holding long-lived sessions — customer credit apps, persistent-cart cookies that survive logout — will need their own re-issuance. Most reputable ones handle the 401 fallback gracefully. A handful of older SaaS integrations don't, and you're going to hear from whoever runs them first.

Routine Refresh vs. Break-Glass Rotation

Salt rotation has no schedule. There is no monthly obligation, no quarterly cleanup tied to a compliance calendar. Treat it as a deliberate action you take when the situation actually calls for one. Conflating "best practice" with "every Tuesday" wastes operational budget and spams your customer base with re-auth events they don't need.

Rotate when one of these shows up in your incident log:

• A device leaving the building — a contractor's laptop, a former employee's phone, a freelancer's machine that wasn't fully revoked.

• Suspicious session activity you can correlate to a specific user: logins from unfamiliar ASNs, simultaneous sessions from different countries, repeated 401 bursts that get auto-recovered.

• A leaked `wp-config.php` exposure, whether via backup dump, SFTP mistype, or shared-drive slip. The whole file is sensitive — keys, salts, DB credentials, table prefix — so any exposure is a rotation trigger.

• Post-incident cleanup after a malware removal. Salt rotation doesn't scrub installed malware — handle that as a separate track, then rotate keys to seal the session-layer access alongside the file cleanup.

Don't rotate on a calendar. The compound cost of weekly logouts across your customer base adds up: every logout is one re-authentication, and re-authentication is a measurable conversion dropoff. Treat salts like emergency services — never call them when nothing is on fire.

That broader posture — refreshing credentials, auditing access, tightening defaults — is the same hygiene applied to every online account you run your business from. Outside of WordPress itself, general lifestyle and digital-hygiene resources like Cosmo2tree round up the kind of practical reminders worth folding into your store's broader security checklist.

Pitfalls That Catch Store Owners Off Guard

• Editors lose unsaved drafts. A logged-out editor hitting "Update" on a 2,000-word post gets bounced to the login screen, and the draft may or may not survive the round trip. Force the rotation, but warn the team first.

• Cron-based exports fail mid-run. Any background task holding a nonce context drops its action token the moment keys change. Re-trigger after the cut.

• Two-factor plugins lose device pairing. Some 2FA setups cache session-bound state. Users log back in, but their second factor asks them to re-link — budget a handful of support tickets for the hour after a forced rotation.

• Backup plugins on tight schedules can fire on the cusp of a rotation and capture the new keys mid-window. Sanity-check the most recent backup for parseability.

• Reversing the values by accident isn't destructive, but you end up with mismatched rotation timing — half your cookies validate, half don't. The breach still closes, but you inherit a debugging session nobody wants.

Salt rotation is the cheapest, fastest kill-switch in your WordPress stack: one file, four constants, full session wipe. Done reactively, it shuts down a hijacked cookie before the attacker can pivot to anything meaningful. Done routinely without a reason, it costs you conversion events and trust for zero defensive gain. Treat it like the emergency break it is — pull it when the dashboard lights up, leave it untouched when nothing is on fire.

For a store owner, the math is short. Lost carts from a coordinated session-fix attack cost more than the brief checkout friction of a one-time forced logout. Keep your salt-rotation runbook ready, generate from the official source, edit `wp-config.php` directly, and don't apologize for being aggressive when the symptoms warrant it. Everything else — strong passwords, two-factor authentication, hardened file permissions, monitored logins — stays in the toolkit alongside it. None of those are substitutes for one another. Each defends a different surface, and the entire stack is what holds.