How to Generate WordPress Security Salts & Authentication Keys in 2026

What Are WordPress Security Salts?

WordPress security salts are eight unique cryptographic strings defined in your wp-config.php file. They work alongside four authentication keys to hash and encrypt the data stored in your browser cookies and session tokens. Without strong salts, an attacker who intercepts a session cookie could reverse-engineer it and hijack your WordPress admin session.

The eight constants WordPress expects are: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, and their corresponding salt counterparts AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, and NONCE_SALT. Each should be a unique, random string at least 64 characters long.

Think of salts as a secret seasoning added to your password hashes and session cookies. Even if two users have the same password, the salted hash will be different. Without salts, WordPress falls back to weaker default hashing — leaving your entire authentication layer exposed to brute-force cracking and rainbow table attacks.

Why You Should Rotate WordPress Salts Regularly

Most WordPress installations set their security salts once during the original setup and never change them again. This is a significant security risk. If your salts are ever exposed — through a database backup leak, a compromised staging environment, a developer’s machine being hacked, or a misconfigured server that briefly served wp-config.php as plain text — every hashed value on your site becomes vulnerable.

Rotating salts is the fastest way to invalidate all active sessions site-wide. When you change the salt values in wp-config.php, every existing logged-in session immediately becomes invalid. All users (including any attacker holding a stolen session cookie) are forced to re-authenticate. This single action has contained more WordPress security breaches than most people realize.

When to rotate salts: after any suspected breach, when removing a team member’s access, after restoring from a backup, and on a regular quarterly schedule for production sites handling sensitive data. The process takes under 30 seconds and causes zero downtime.

How to Generate Strong WordPress Salts

There are three common methods for generating WordPress security salts, each with different tradeoffs:

1. The WordPress.org secret-key API — The official endpoint at api.wordpress.org/secret-key/1.1/salt/ generates salts on demand. The downside is that you’re trusting a third-party server with your cryptographic keys, and the connection must be over HTTPS. If your server’s TLS certificate chain is misconfigured, you could be receiving salts over an insecure connection without realizing it.

2. Client-side generation — Tools that generate salts in your browser using crypto.getRandomValues() never transmit your keys over the network. This is the most secure approach because the keys exist only in your browser memory until you copy them. The FyrePress Salts Generator uses this approach exclusively.

3. WP-CLI command — Running wp config shuffle-salts regenerates salts directly on the server. This is ideal for automated workflows and CI/CD pipelines, but requires SSH access and WP-CLI installed on the server.

Adding Salts to wp-config.php: Step by Step

Once you’ve generated your eight salt and key constants, adding them to your WordPress installation is straightforward:

Step 1: Connect to your server via SFTP, SSH, or your hosting panel’s file manager. Navigate to your WordPress root directory (where wp-config.php lives).

Step 2: Open wp-config.php in a text editor. Find the section that reads put your unique phrase here — this is the default placeholder WordPress ships with.

Step 3: Replace all eight define() lines with your newly generated values. Make sure each constant has a unique value — never reuse a salt across two constants.

Step 4: Save the file and upload it back to the server. All active sessions will be invalidated immediately, and every user will need to log in again.

define('AUTH_KEY',         'your-unique-64-char-random-string-here');
define('SECURE_AUTH_KEY',  'another-unique-64-char-random-string');
define('LOGGED_IN_KEY',    'yet-another-unique-random-string-here');
define('NONCE_KEY',        'a-different-unique-random-string-here');
define('AUTH_SALT',        'unique-salt-string-not-reused-anywhere');
define('SECURE_AUTH_SALT', 'separate-unique-salt-for-this-constant');
define('LOGGED_IN_SALT',   'individual-unique-salt-for-logged-in');
define('NONCE_SALT',       'final-unique-salt-for-nonce-validation');

Never edit wp-config.php directly from the WordPress admin dashboard or through a plugin — a syntax error in this file will take your site offline instantly. Always keep a backup of the previous version before making changes.

Common Salt Configuration Mistakes

Even experienced developers make these errors when managing WordPress security salts:

• Using the same value for multiple constants — Each of the eight constants must be unique. Reusing a value undermines the entire purpose of salting.
• Using short or predictable strings — Phrases like mysecretkey123 can be cracked in seconds. Use at least 64 characters with mixed-case letters, numbers, and special characters.
• Leaving the defaults in place — If your wp-config.php still contains put your unique phrase here, your site is using no real salt protection at all.
• Storing salts in version control — Never commit wp-config.php to Git. Anyone with repository access would have your production cryptographic keys.
• Not rotating after team changes — When a developer leaves the team, they may still have cached versions of your salts. Rotate immediately.

Beyond Salts: Complementary Security Layers

Strong salts are just one layer in a defense-in-depth strategy. To fully protect your WordPress installation, combine salt management with these additional measures:

Server-level protection — Your .htaccess file should block direct access to wp-config.php, preventing it from ever being served as plain text even if PHP processing fails. The .htaccess Generator includes this rule by default.

HTTP security headers — Headers like X-Content-Type-Options and Strict-Transport-Security add browser-level protections that work alongside your server-side salt configuration. Use the Security Headers Generator to build the complete header block.

Login endpoint hardening — Moving your login URL from the default /wp-login.php reduces brute-force attempts. The Login URL Obfuscator generates the rewrite rules automatically.

Version exposure — WordPress version numbers exposed in meta tags help attackers target known vulnerabilities. The Hide WP Version Number tool strips this information from every public output.

Frequently Asked Questions