Security keys in WordPress are a set of cryptographic constants defined in the wp-config.php file that are used to encrypt and secure sensitive data — particularly the cookies and authentication tokens that keep users logged in to the WordPress admin. They work alongside corresponding “salts” (random strings appended before hashing) to make stored authentication data computationally impractical to reverse-engineer or brute-force.
Every WordPress installation includes eight constants in wp-config.php: four security keys (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY) and four corresponding salts (AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, NONCE_SALT). When a user logs in, WordPress uses these constants to create an encrypted version of the login cookie. Without the correct keys and salts, that cookie is meaningless — which means that even if an attacker intercepts a session cookie, they can’t use it to authenticate without knowing the secret values stored on the server.
How WordPress Security Keys Work
When you log in to WordPress:
- WordPress takes your username, password hash, and other session data.
- It combines this data with the relevant security key and salt constants from
wp-config.php. - The combined data is hashed (one-way encrypted) and stored as a cookie on the user’s browser.
- On subsequent page loads, WordPress recalculates the expected cookie value and compares it to what the browser sends. If they match, the session is valid.
If the security keys are changed, all existing cookies become invalid immediately — every logged-in user, including administrators, is logged out. This behavior is useful as a security response: if you suspect a site has been compromised, resetting the keys immediately invalidates any active attacker sessions.
WordPress generates default security keys automatically on installation. However, if the wp-config.php file was generated without them (older installations) or if the default placeholder values were never replaced, the security benefit is significantly reduced.
[Image: Screenshot of the wp-config.php security keys section showing the eight AUTH_KEY, SECURE_AUTH_KEY, etc. constants with random-looking values]
Purpose & Benefits
1. Protect Against Session Hijacking
Without strong, unique security keys, an attacker who intercepts a session cookie could potentially reconstruct valid authentication credentials. With properly generated keys and salts, intercepted cookies have no value — the encryption can’t be reversed without server-side access to wp-config.php. This is a foundational layer of WordPress hardening.
2. Invalidate Compromised Sessions Instantly
If your site is hacked, credentials are exposed, or you suspect unauthorized access, resetting the security keys is one of the fastest ways to cut off active attacker sessions. Changing the keys logs out every user simultaneously — forcing re-authentication with fresh, clean session cookies. This is a standard step in WordPress incident response.
3. Add Depth to WordPress Authentication Security
Security keys work best as part of a layered approach. Combined with two-factor authentication (2FA), strong passwords, and a properly locked-down wp-config.php file, they make authentication substantially harder to compromise. Each layer addresses a different attack vector; security keys specifically protect the persistence layer (staying logged in), not the initial login process.
Examples
1. Initial Site Setup
A WordPress developer configures a new client site. Rather than using the placeholder values that were copied from a sample wp-config.php, they use WordPress.org’s secret key generator (https://api.wordpress.org/secret-key/1.1/salt/) to generate a fresh set of eight unique, random constants. This ensures the site launches with production-quality security from day one.
2. Post-Hack Incident Response
A site owner discovers that their WordPress admin was compromised. As part of cleanup, they change all admin passwords, update security keys, and regenerate salts. This immediately invalidates the attacker’s active session cookies — even if the attacker had bookmarked a backdoor login — and ensures any sessions established during the compromise period are revoked.
3. Routine Security Rotation
A managed WordPress hosting provider automatically rotates security keys every 90 days as part of their security hardening process. This limits the window in which any compromised session cookie could remain valid, even if the compromise hasn’t been detected. Plugins like Salt Shaker automate this rotation without requiring manual wp-config.php edits.
Common Mistakes to Avoid
- Leaving placeholder values in place — Some
wp-config.phptemplates include comments like “put your unique phrase here” instead of actual random values. Sites deployed with these placeholders have essentially no cookie encryption. Always generate real values from the WordPress.org key generator. - Storing wp-config.php insecurely — Security keys provide strong protection only if
wp-config.phpitself is protected. The file should have restricted read permissions, be placed above the web root where possible, and never be accessible via the browser. A leakedwp-config.phpexposes all authentication data. - Forgetting that key changes log everyone out — Rotating security keys is a maintenance operation that needs coordination. Changing keys during business hours without notice will log out all active users and admins simultaneously. Schedule rotations during off-peak periods.
- Not including key rotation in post-hack cleanup — It’s common to focus on removing malware and updating passwords after a breach while forgetting to rotate security keys. If an attacker had access to
wp-config.php, they have the old keys — which remain valid until changed.
Best Practices
1. Generate Keys From the Official WordPress API
Always use the WordPress.org secret key service (https://api.wordpress.org/secret-key/1.1/salt/) to generate security keys. This tool produces cryptographically random values designed specifically for this purpose. Never create keys manually or use predictable strings — the randomness of the values is what makes them effective.
2. Rotate Keys Periodically or After Security Events
In our experience, most WordPress sites run with the same security keys for years — sometimes since the initial installation. Rotating keys every 6–12 months is a reasonable practice for most sites. After any confirmed or suspected compromise, key rotation is mandatory as part of incident response. Consider plugins that automate rotation on a schedule to remove the manual overhead.
3. Protect wp-config.php at the Server Level
Security keys are only as secure as the file that contains them. Restrict wp-config.php file permissions (644 or stricter), block direct browser access via .htaccess rules, and ensure it’s included in your backup and excluded from any public file access. This is covered in any thorough WordPress hardening checklist.
Frequently Asked Questions
What happens if I don’t have security keys in my wp-config.php?
WordPress will still function, but cookie-based authentication data will be stored and validated with weak or no encryption — significantly reducing protection against session hijacking. Older WordPress installations sometimes have placeholder values or missing keys. Generating and adding proper keys immediately improves security.
Will changing security keys break my site?
No — it won’t affect the site’s functionality or content. The only effect is that all currently logged-in users (including you as admin) will be logged out immediately and must re-authenticate. The site continues to operate normally. Plan the rotation for a low-traffic period to minimize disruption.
Are security keys the same as API keys?
No. WordPress security keys are specifically for encrypting authentication cookies — they’re internal to WordPress. API keys are credentials used to authenticate with external services and APIs. They serve different purposes and are stored and managed differently.
Do security keys protect against brute-force login attacks?
Not directly. Security keys protect session data after a user is already logged in, not the login process itself. Protection against brute-force attacks requires login attempt limiting, 2FA, and CAPTCHA. However, all of these controls work together as part of a complete WordPress hardening approach.
Should I use the same security keys on a staging site?
No. Your staging site and production site should each have their own unique security keys. Sharing keys between environments is a security risk — a compromise of the less-protected staging environment could expose keys that apply to the production site.
Related Glossary Terms
How CyberOptik Can Help
Security keys are one piece of a broader WordPress security picture. We configure and maintain WordPress security settings — including key management, hardening configurations, and ongoing monitoring — for clients on our managed hosting plans. If your site hasn’t had a security review in a while, it’s worth checking. Learn about our hosting solutions or contact us to discuss your WordPress maintenance needs.
