What Do These Eight Values Do?

When a user logs into the WordPress admin panel, cookies identifying their session are written to the browser. To prevent an attacker from forging those cookies, WordPress cryptographically signs every cookie it produces along with many form and AJAX requests. The random character strings used during signing are called security keys or salts. WordPress uses 8 unique constants in total: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY and their _SALT counterparts AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, NONCE_SALT. These constants are defined in the wp-config.php file and run constantly in the background from the moment the site is set up; most site owners are not even aware they exist.

Four Key Pairs, Four Different Jobs

The eight constants are really four pairs serving four different purposes. Each pair consists of a _KEY and a _SALT value; together they produce the signature of the relevant cookie.

  • AUTH_KEY / AUTH_SALT: signs the user's general authentication cookies; this is the basic authentication layer used when logging into wp-admin.
  • SECURE_AUTH_KEY / SECURE_AUTH_SALT: provides a separate signing layer for the authentication cookies used when the connection is made over SSL/HTTPS.
  • LOGGED_IN_KEY / LOGGED_IN_SALT: signs the cookie used to recognise the user's "logged in" state on the site's frontend as well as outside the admin panel; recognising a logged-in user in comment forms, for instance, relies on this.
  • NONCE_KEY / NONCE_SALT: used in generating the single-use "nonce" (number used once) tokens employed in forms and AJAX requests; these tokens protect against CSRF-style forged request attacks.

Using separate key sets for four different purposes is a matter of layered defence: having the signing mechanism for one cookie type work independently across different contexts (admin panel, frontend, forms, SSL) makes it harder for a weakness at a single point to affect the whole system.

How It Looks Inside wp-config.php

These eight constants are defined with define() lines in the wp-config.php file in the installation's root directory. The example below shows the structure of those lines; the values there are placeholders only and do not represent real key generation:

When and Why You Should Regenerate the Keys

Changing the keys may look like a small maintenance job at first glance, but it has a direct consequence: it instantly invalidates all existing sessions and "remember me" cookies. After this change every user, including you, has to log in again. That behaviour is in fact proof of what the keys do: no cookie produced with the old signatures is accepted as valid any more.

  • When you suspect a security breach: regenerating the keys after noticing an unauthorised admin account, an unexplained file change or suspicious login attempts is a well-known first incident response step.
  • When moving a site to another server or restoring it from an old backup, using a fresh key set is an extra hygiene step.
  • As part of periodic maintenance — once a year, for example — refreshing the keys is in line with general security practice.
  • When you suspect an administrator account's password may have been compromised, regenerating the keys in addition to changing the password closes all existing sessions.

Example Scenario: After a Suspicious Login

Say you notice an unusual administrator session in your site traffic or an admin account you do not recognise. In a situation like that, regenerating the keys is a fast and effective step you can take before the incident grows. The process runs roughly as follows:

  • First, the suspicious admin account's password is changed or the account is removed entirely.
  • Next, new random values are generated for the eight security keys.
  • These new values are pasted in place of the existing define() lines in the wp-config.php file and the file is saved.
  • Once it is saved, every active session on the site becomes invalid, including any forged sessions the attacker may have produced with the old cookies.
  • Everyone, you included, has to log in again to the panel and to the membership area if there is one.

This step alone does not fully resolve a security breach; it should be applied together with other measures such as malicious file scanning, plugin/theme updates and password resets. But because it invalidates existing sessions instantly, it is one of the first and lowest-cost steps in incident response.

Common Mistakes

  • Leaving the default placeholder text such as "put your unique phrase here", found in WordPress's official installation skeleton (wp-config-sample.php), unchanged.
  • Copying and pasting the same string into all eight constants; this removes the isolation between the different cookie types.
  • Changing the password but skipping key regeneration when suspicious activity is noticed; a session cookie signed with the old keys may still remain valid.
  • Writing the keys by hand with a predictable pattern (the site name, a date, simple words); the strength of these values comes entirely from their randomness.
  • Editing the wp-config.php file without taking a backup first; a single bad line can make the site completely inaccessible.

Using a generator instead of making up the keys by hand is both faster and safer. This tool uses crypto.getRandomValues() and picks from the same character set (letters, digits and special characters) as WordPress.org's official key generator API (api.wordpress.org/secret-key/1.1/salt/). Generation happens entirely in your browser; no value is sent to any server. All you need to do is copy the eight lines produced and paste them in place of the existing definitions in your wp-config.php file.