What Are WordPress Salts & How Do They Protect Your Site?

WordPress salts are cryptographic tools that protect WordPress websites by making authentication cookies difficult to forge or steal. They build unpredictability into security keys, expanding on traditional password protection to better safeguard users and websites against risks like session hijacking.

Salts add complexity to one-way cryptographic transformations known as hashing. This stronger hashing process protects login details and the cookies WordPress uses to maintain user sessions. Although useful, they represent just one layer in a comprehensive security strategy that, ideally, will also include defenses such as malware scanning (and removal), vulnerability patching, web application firewall (WAF), and more.

Why WordPress salts matter for security

WordPress salts amplify existing security strategies by making login sessions and authentication cookies more difficult for threat actors to compromise. They help protect against risks like session hijacking while reinforcing the overall security of the login process. Passwords alone do not always provide sufficient protection, but adding salts makes authentication systems more resilient.

Without salts, attackers could easily decode or reuse raw hashed values, simply because those hashes would become predictable. Salts eliminate this predictability, making every stored value truly unique. This limits the overall security impact if credentials are stolen or if sessions are compromised.

How do WordPress salts work?

WordPress uses a series of integrated mechanisms to protect login sessions: security keys, salts, hashing, and cookies. Security keys make authentication data difficult to decode, with cryptographic hash functions transforming that data into fixed-length strings that cannot be reversed.

On their own, security keys help secure authentication data, but without salts, hashed values can be more vulnerable to certain attack methods. As a result, sophisticated attackers may still be able to exploit stolen session data.

This is where WordPress salts come into play. They add randomness to the equation, delivering unique hashes that are far more difficult for attackers to analyze or exploit.

This protects against session hijacking, in which attackers attempt to reuse authentication cookies to gain unauthorized access. When hashed data is more unique (due to salts), stolen cookies become more difficult for hackers to understand or recreate.

Salts can also help prevent attacks involving precomputed rainbow tables; these tables are meant to cache cryptographic hash function outputs, but become less useful to attackers once salts are added. This limits the efficacy of attackers' large-scale password-cracking efforts.

WordPress salts vs security keys: what’s the difference?

Salts and security keys are both critical components of the overarching WordPress authentication system. Security keys sign and validate data, while salts add unpredictability to that data. These elements work together to keep login sessions secure.

Where are WordPress salts stored?

WordPress generates unique salts and security keys during installation. These can be found in the wp-config.php file (under Authentication Unique Keys and Salts). This WordPress arrangement actually consists of keys and corresponding salts. They are tied to different aspects of login sessions, with all eight residing within the wp-config.php file. All end in KEY or SALT.

• AUTH_KEY and AUTH_SALT. Meant to protect primary authentication cookies, these keys and salts validate the user's session legitimacy. As a result, authentication cookies become difficult to forge.
• SECURE_AUTH_KEY and SECURE_AUTH_SALT. Similar to auth keys and salts, this version emphasizes Hypertext Transfer Protocol Secure (HTTPS) sessions, adding an extra layer of protection as data is transmitted via encrypted connections.
• LOGGED_IN_KEY and LOGGED_IN_SALT. Validating cookies for logged-in users who do not immediately require active access to admin functions, these keys and salts boost continuity without escalated privileges.
• NONCE_KEY and NONCE_SALT. Centered around arbitrary numbers used once (nonces), these keys and salts protect short-lived tokens in an effort to combat Cross-Site Request Forgery (CSRF) attacks.

How do you change WordPress salts?

WordPress salts can be changed to invalidate stolen authentication cookies. This strengthens security following suspected breaches or malware cleanups. WordPress provides an official salt generator, capable of producing fresh sets of values.

From there, the File Transfer Protocol (FTP) or hosting file manager can be used to access the wp-config.php and its authentication keys and salts section. Previously mentioned values, such as AUTH_SALT, are replaced simply by deleting old lines and pasting new ones from the WordPress salt generator.

Manual strategies for changing salts are straightforward, but security plugins (including solutions like the Salt Shaker plugin) can expedite this process by automatically handling updates so that salts are refreshed correctly. Keep in mind that, as salts and keys are changed, active users are logged out of their sessions and forced to sign in once again.

WordPress salts best practices

WordPress salts are a core part of authentication and are defined in the wp-config.php file. That being said, these salts can be approached differently depending on individual security knowledge or preferences. Best practices for leveraging the security advantages of WordPress salts include:

• Always verify salts during setup. WordPress generates unique salts with every new installation, but it’s still worth confirming they are properly set, especially when working with manual installs, older sites, or environments where they may not have been updated.
• Keep salts private. If salts end up in the wrong hands, threat actors could impersonate legitimate users or otherwise compromise seemingly strong authentication systems. Salt privacy is best safeguarded by protecting the wp-config.php file. In many cases, strict file permissions will be sufficient.
• Update salts after suspected breaches. Security incidents that expose files or environments also compromise authentication data. If attackers gain access to the wp-config.php, they can access WordPress security keys or salts. These, in turn, could allow attacks to maintain site access. Updated salts invalidate sessions and force new logins, thereby cutting off unauthorized access.
• Avoid unnecessary frequent changes. While WordPress salts occasionally need to be changed, more isn't always better. Excessive rotations complicate site management without meaningfully improving security. Focus on event-driven rotation (especially after suspected breaches), but add occasional rotation for maintenance if desired.

Why are WordPress salts alone not enough to secure your website?

While salts strengthen authentication and build on existing security solutions, they do not address broader website security risks.

These are meant to support security, not serve as a primary solution. Alone, WordPress salts are unlikely to block these attacks:

• Brute force attacks. Although WordPress salts can make authentication cookies more difficult to exploit, they won't stop attackers from attempting to log in. Additional protection (such as firewalls) limits attempts, providing an even stronger defense.
• Vulnerabilities. Salts are incapable of patching vulnerabilities that emerge in WordPress files or in the core. Without patching, threat actors can exploit security flaws, even when temporarily sidelined by strong salts.
• Outdated plugins. Poorly updated plugins are among the most common and accessible entry points for threat actors. Salts help, but do not account for missed updates or weaknesses in the code. In fact, exploitable plugins could potentially allow attackers to bypass authentication altogether.
• Malware. Outdated plugins and compromised themes are often responsible for malware attacks, but salts are not built to address these concerns. Once malware strikes the file systems, salts can no longer stop attackers from injecting harmful scripts or modifying files. They do not detect infections or remove malicious files.

Ultimately, salts form a single, but important layer within a broader WordPress security plan. They should be accompanied by comprehensive security solutions that address many sources of risk.

What else do you need to secure your WordPress site?

While salts help secure authentication, these additional layers address threats that occur outside the login process:

• Malware scanning. WordPress files, databases, and core components should be scanned continuously for issues such as modified files or malware signatures. The goal is to catch infections in their earliest stages — before they have the chance to spread further or to compromise user accounts. Automated scanning solutions operate in the background, removing the need for time-consuming manual checks.
• Firewall protection. Designed to filter incoming traffic, web application firewalls block malicious requests while forming a critical front-line barrier. These firewalls provide robust protection against brute force attempts as well as SQL injections.
• Comprehensive monitoring. Solutions should go beyond malware scanning to identify emerging threats and respond in real-time. Automated remediation removes malware and resolves issues without requiring manual intervention, ticket submissions, or delays, helping teams maintain site security without added operational overhead.

How SiteLock helps protect WordPress sites

Putting these layers into practice requires tools that can manage detection, protection, and remediation in one place. SiteLock's free WordPress security plugin provides baseline hardening within WordPress, reducing exposures to known threats.

SiteLock’s tiered security plans can be connected as needed to expand protection with live attack blocking and automated malware removal. The Site Health Score provides a clear view of overall risk, while Prioritized Tasks highlight the most critical issues to address first. This removes the need to interpret complex security data and helps teams take action quickly.

Together, these features give site owners a clear, actionable path to improve and maintain website security.