security

Security Key (Salt)

A WordPress security key (also called a salt) is a random string of characters added to authentication credentials before hashing, making it computationally infeasible for an attacker to reverse-...

Security Key (Salt)

Affiliate disclosure: Some links on WPSchool are affiliate links. This glossary entry is educational and contains no affiliate recommendations.

Last verified: April 2026

A WordPress security key (also called a salt) is a random string of characters added to authentication credentials before hashing, making it computationally infeasible for an attacker to reverse-engineer a stolen cookie or password hash.


What Is a WordPress Security Key?

WordPress stores eight security keys and salts in wp-config.php: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, and four corresponding _SALT constants. These values were introduced in WordPress 2.6 (2008) and have been required ever since. When a user logs in, WordPress combines their credentials with these constants before hashing — so even if two users have identical passwords, their stored hashes look nothing alike.


Why It Matters on Your Site

Every WordPress site we audit is running with one of two problems: default placeholder keys that were never replaced, or keys that have never been rotated after a suspected breach. On shared hosting especially, we see stale keys on 30–40% of client installations. A compromised wp-config.php hands an attacker the ability to forge valid authentication cookies for any account on the site — including admin.

Regenerating your security keys is one of the fastest, lowest-risk security actions available. It invalidates all active login sessions site-wide, forcing every user to re-authenticate against new hashed values.


How to Update Your Security Keys

WordPress provides an official secret key generator that produces eight cryptographically random constants on every request. Copy the output, open wp-config.php, and replace the existing block.

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

After saving, every logged-in session — including yours — is immediately invalidated. Log back in and you’re protected by the new values.

One gotcha we surface constantly on client sites: if you’re using a caching plugin, purge your full-page cache immediately after rotating keys. Cached pages can retain session fragments tied to old hash values, which produces confusing login-loop errors for returning visitors.


When to Rotate Security Keys

Rotate your keys whenever:

  • You suspect a wp-config.php exposure (server breach, leaked backup, misconfigured file permissions)
  • A user with admin access leaves your organization
  • You restore from a backup taken during a known attack window
  • It has been more than 12 months since the last rotation

  • wp-config.php — the core configuration file where security keys are stored
  • Cookie authentication — the mechanism WordPress security keys directly protect
  • Password hashing — the broader cryptographic process salts augment
  • Nonce — a single-use token in WordPress that also depends on security keys for integrity
  • Two-factor authentication (2FA) — a complementary login protection layer

Additional Reading