What Are WordPress Salts and How They Protect Sites

Over 43% of all websites run on WordPress, making it a major target for cyberattacks. In fact, Sucuri reports show that over 90% of infected CMS sites in recent years were WordPress-based. While plugins and firewalls help, few users know that your wp-config.php file holds one of your site’s strongest defenses: salts.

These cryptographic keys silently guard your login sessions, cookies, and authentication data. In this guide, we’ll break down what WordPress salts are, how they work, and how you can manage them—manually or with tools like InstaWP—to keep your sites and users fully protected.

What Are WordPress Salts?

At a high level, WordPress salts are cryptographic variables that work with authentication keys to securely store and validate user session data like login credentials and cookies.

In more practical terms, they’re randomized strings of text that add complexity and security to the way WordPress hashes sensitive data like passwords, login cookies, and nonces.

When a user logs into WordPress, their credentials are stored temporarily in browser cookies—like wordpress_[hash] and wordpress_logged_in_[hash]—to keep them logged in without forcing a password entry on every page load. This is great for UX, but a potential risk if cookies are stolen or intercepted.

That’s where salts come in.

Salts + Keys = WordPress’s Secret Weapon

In WordPress, these two terms go hand-in-hand:

• Authentication Keys: These are predefined constants like AUTH_KEY, LOGGED_IN_KEY, etc. They are used to generate hashes of sensitive data.
  
• Salts: These add an extra randomized value to each hash, making them even more secure and unique for your site.
  

Together, they ensure that even if someone somehow obtains your cookies or database, they can’t reverse-engineer your actual password or session data. Salts prevent the use of common attacks like dictionary attacks or rainbow table lookups by ensuring that the hashed values are unique for your site and your current session.

Real-World Analogy: Why Salting Works

Imagine your WordPress password is the word apple. If an attacker gains access to your database and your site doesn’t use salts, they may find a hash that corresponds directly to apple—a known value that can be cracked in seconds using precomputed tables.

Now introduce a salt: a long, randomized string like G*9hs#73>!fw35P. Instead of hashing apple, WordPress now hashes appleG*9hs#73>!fw35P.

Even if an attacker knows you’re using the word apple, they have no idea what salt you’re using, making the resulting hash unrecognizable and unbreakable without access to your config file.

Salting ensures that even the same password produces a completely different hash on different WordPress sites. That’s the power of cryptographic uniqueness.

Where Are WordPress Salts Stored?

Salts and keys are defined in your WordPress site’s wp-config.php file, located in the root directory of your installation (usually /public_html/ or /htdocs/).

You’ll see them defined like this:

These eight values work in pairs. The four keys handle encryption and validation logic. The four salts inject randomness into the hashing process, making each value unique to your installation.

You’ll also find a helpful comment in this section of the file, directing you to the official WordPress salt generator—a tool that provides a fresh set of cryptographically secure values every time you refresh the page.

Are WordPress Salts Set Automatically?

Yes—but only once.

When you install WordPress for the first time, salts and keys are auto-generated and written into wp-config.php. But here’s the catch: they never update again unless you manually change them.

That’s a problem because static salts can eventually become a liability. If anyone gains access to your wp-config.php (through a vulnerability or misconfiguration), your login cookies and hashed data can be reverse-engineered using those same salts.

That’s why security-conscious developers and agencies recommend rotating salts regularly, especially after:

• A team member leaves
  
• A plugin is compromised
  
• You’ve logged into WordPress from an unknown network
  
• You suspect malicious activity on the site
  

How WordPress Salts Work Behind the Scenes

Understanding how WordPress salts work will help you see just how important they are—not just for encryption, but for keeping session data safe, protecting cookies, and preventing unauthorized logins. While most of this happens silently in the background, knowing how it works helps you take full control of your site’s security configuration.

What Happens When You Log In to WordPress?

Let’s say a user logs into your WordPress site. Behind the scenes, here’s what WordPress does to handle that authentication:

1. The user enters a username and password.
   
2. WordPress hashes the password using a cryptographic algorithm and checks it against the database.
   
3. If valid, WordPress sets cookies in the user’s browser: wordpress_[hash] and wordpress_logged_in_[hash].
   
4. These cookies include encrypted data about the session, like user ID and expiration time.
   
5. This session data is hashed again, using authentication keys and salts from the wp-config.php file.
   

Only if the data matches and the hashing is valid will the user remain logged in across sessions.

The result? Even if someone steals that cookie file, it’s useless without the matching salts and keys.

Imagine you and 1,000 other people all have the same password: admin123.

If all of your WordPress installs use the same hashing method but no salts, then all 1,000 hashes will look the same. An attacker who cracks one hash has cracked them all.

Now introduce a unique salt per site—say, F9sd*#%kLp. When WordPress hashes admin123F9sd*#%kLp, it produces a result that is unique to that site. Even if another site uses the same password, the hash will be different because the salt is different.

Salts essentially make brute-force and rainbow table attacks mathematically useless.

The Role of wp_salt() in WordPress Core

The magic happens in a WordPress core function: wp_salt().

function wp_salt( $scheme = ‘auth’ ) {

    // returns a combination of keys and salts for the specified auth scheme

}

This function:

• Retrieves or generates salt values based on the authentication type: auth, secure_auth, logged_in, nonce
  
• Applies a filter (apply_filters( ‘salt’, …)) allowing plugins to customize or override salts
  
• Combines values from constants defined in wp-config.php or generates them if not present
  

This level of flexibility allows advanced users or plugins (like Salt Shaker or security suites) to rotate and reapply salts as needed.

Hashing vs Salting: Know the Difference

These two terms are often used together, but they serve different purposes in WordPress security:

For example, hashing password123 without a salt might result in:
482c811da5d5b4bc6d497ffa98491e38

But with a salt (Z8f5@%#J!*s) added, the input becomes password123Z8f5@%#J!*s, and the hash becomes something completely different:
3a4f8e01cb2cd6735f74b4a9e3c676fb

Without the WordPress salts, any attacker with access to common hashes could reverse-engineer the password. With the salt, even if they guess the password, they can’t replicate the hash without knowing the salt.

What Makes WordPress Salting So Effective in Securing a Site 

While it takes a lot to secure WordPress, salts are considered one of the most powerful yet underrated security measures. 

Dynamic per installation: Each site has different salts, making widespread cookie hijacking nearly impossible

Immutable by attackers: Salts are stored server-side in wp-config.php, inaccessible to front-end exploits

Session reset effect: Changing salts immediately invalidates existing sessions, forcing re-authentication

This makes salting one of the most low-effort, high-impact security upgrades you can manage as a site owner or agency.

How to Change WordPress Salts Safely (3 Methods)

By now, you know that WordPress salts protect your site’s login credentials and session data. But here’s the critical catch: they don’t update automatically. Once set during installation, they remain static unless you manually refresh them.

Changing your salts periodically is a smart way to:

• Revoke all existing sessions (especially useful after a potential breach)
  
• Lock out unwanted users
  
• Strengthen site security by eliminating stale credentials
  

Here are the three most effective ways to change your WordPress salts—no matter your level of access or experience.

Method 1: Change Salts Manually in wp-config.php

This method is ideal for developers or agencies who prefer direct file-level control.

1. Access your site’s file system
   
   • Use FTP, cPanel’s File Manager, or a local terminal (if self-hosted). We’re using the FTP method as our test site is hosted on a managed WordPress hosting.
     
   • Navigate to your site’s root directory (often called public_html or /htdocs).
     
2. Open the wp-config.php file

This file is located in the root of your WordPress installation. Make a backup before editing—always.

Locate the salt and key section
You’ll find a block that looks like this:

define(‘AUTH_KEY’,         ‘your-random-string’);

define(‘SECURE_AUTH_KEY’,  ‘your-random-string’);

define(‘LOGGED_IN_KEY’,    ‘your-random-string’);

define(‘NONCE_KEY’,        ‘your-random-string’);

define(‘AUTH_SALT’,        ‘your-random-string’);

define(‘SECURE_AUTH_SALT’, ‘your-random-string’);

define(‘LOGGED_IN_SALT’,   ‘your-random-string’);

define(‘NONCE_SALT’,       ‘your-random-string’);

3. Generate new salts securely
   
   • Visit the official WordPress Salt Generator
     
   • Copy all 8 freshly generated lines.
     
4. Replace the old block with the new one
   
   • Paste the new values directly over the existing keys and salts.
     
   • Save and re-upload the file if editing locally.
     
5. Result
   
   • All users will be logged out immediately.
     
   • Any stolen or active cookies are now invalid.
     

Important Notes:

• Don’t refresh the generator multiple times and use different salts from different tabs.
  
• Make sure there are no syntax errors in wp-config.php, or your site may crash.
  

Method 2: Automate Salting with a Plugin 

If you’re not comfortable editing core files—or if you want to automate regular salt rotation—this method is for you.

1. Go to Plugins → Add New in your WordPress dashboard

2. Search for Salt Shaker or any other WordPress salt generator plugins
3. Install and activate the plugin
4. Navigate to Tools → Salt Shaker
   

You’ll see two options:

• Change Now – Regenerates salts immediately

• Schedule Changes – Automatically rotate salts on a set interval:
  
  • Daily
    
  • Weekly
    
  • Monthly
    
  • Quarterly
    
  • Biannually
    

This is particularly useful for agencies managing multiple sites or for e-commerce websites with sensitive user sessions.

Pro Tip for Agencies & Freelancers

When managing multiple client sites:

• Rotate salts quarterly or immediately after team offboarding
  
• Use InstaWP for non-disruptive testing before pushing to live
  
• Automate the process with Salt Shaker only if you monitor the site regularly (sudden logout behavior may confuse users)
  

What Happens After You Change WordPress Salts?

Now that you’ve changed your WordPress salts—whether manually, through a plugin, or using InstaWP—you may be wondering: What exactly changed under the hood?

The short answer: you’ve instantly invalidated every active session on your site.
But let’s explore exactly what that means and how it affects users, admins, and security workflows.

All Logged-In Users Are Immediately Logged Out

When you update the salts in wp-config.php, WordPress can no longer match existing session cookies with its internal hashing logic. This triggers a full reset of user sessions.

Here’s what happens:

• Any administrator, editor, or subscriber logged into your WordPress site is immediately logged out.
  
• On the next page load, they’ll be redirected to the login screen and asked to authenticate again.
  
• The system effectively treats every existing cookie as invalid.
  

This is not a bug—it’s a security feature.

Why Session Invalidation Is a Good Thing

While it might seem disruptive, logging out all users is actually a strategic security maneuver. Here’s why:

It nullifies stolen cookies

If an attacker had previously gained access to a user’s session cookie, it’s now useless.

It protects shared/public device users

Maybe you—or a team member—forgot to log out on a public terminal or coworking space. Updating salts cuts off any lingering access.

It forces re-authentication after a breach

This is especially critical after recovering from a compromised site or when resetting admin credentials.

Should You Notify Your Users?

If you manage a community site, client portal, or membership platform, it’s a good idea to notify users before changing salts, especially during business hours. Sudden logouts could be mistaken for errors or hacks.

Quick notification template:

“Hi [User],
As part of our routine security enhancements, we’ve updated our login system. You may be logged out and prompted to re-enter your credentials. This is normal and ensures your session remains secure. Thanks for your understanding!”

For agency clients, this also reinforces that you’re proactively protecting their site—a value-add that sets you apart.

Developer Tips: Things to Watch For After Salting

• Multisite Installations: Changing salts on a WordPress multisite affects all networked sites simultaneously. Notify network users accordingly.
  
• WooCommerce Users: Logged-in cart sessions will be reset. If you manage an eCommerce site, schedule salting outside peak hours.
  
• Cookie-Dependent Plugins: Some plugins store lightweight session data in cookies (e.g., analytics opt-ins, custom user roles). These may require reinitialization post-salting.
  

WordPress Salting Best Practices 

If you manage multiple WordPress sites—whether for clients, internal projects, or products—you need more than just a “change once and forget” approach to WordPress salts.

Here are the top best practices to follow, including strategic workflows that combine security with operational ease.

1. Rotate WordPress Salts Regularly

Just like passwords, salts and keys should be updated at intervals—not only after an incident.

Recommended rotation frequency:

• Quarterly for low-activity business sites
  
• Monthly for active blogs, membership platforms, or eCommerce stores
  
• Immediately after staff offboarding, plugin compromise, or password reset
  

Automated plugins like Salt Shaker can help, but it’s even better to make salt rotation part of your scheduled site maintenance checklist.

2. Document Salt Changes During Security Audits

Changing salts is a meaningful security event—it logs out all users and alters how session cookies are validated.

If you’re running an agency or a managed hosting service:

• Log the date of salt change in your internal site documentation
  
• Note who performed the change, and why (routine, breach response, etc.)
  
• Include it in monthly or quarterly maintenance reports for clients
  

This builds trust and transparency—and shows clients you’re proactively safeguarding their digital properties.

3. Avoid Reusing Salts Across Sites

This mistake is more common than you think—especially in mass-deployment environments where developers use prebuilt config templates.

Each WordPress site should have its own unique set of salts and keys. Reusing salts defeats the purpose of salting, as an exploit on one site could compromise others with the same config.

Use WordPress.org’s salt generator for each site setup—or automate this with InstaWP templates that generate new salts per sandbox/site.

4. Don’t Expose Salts in Version Control

Even if your site is private or password-protected, never commit your wp-config.php file (with salts) to Git or any version control system. These keys should remain local and dynamic.

If you’re building development workflows:

• Use .gitignore to exclude wp-config.php
  
• Generate salts at runtime or during deployment with environment variables (for advanced CI/CD setups)
  
• Or manage salts securely within InstaWP without exposing the file
  

Final Word: Secure Your Site at the Source

Most WordPress attacks start where users least expect—through cookies, reused sessions, or exposed credentials. With one small file edit, you can slam that door shut.

Want a safer way to manage and test wp-config.php edits?
Spin up a site in InstaWP and test your salts, cookies, and logout flow in an isolated, rollback-friendly environment. Try InstaWP now — and turn best practices into default practices.