WordPress security keys, salts, and the default table prefix

Most WordPress hardening advice has been written a hundred times: turn off the legacy endpoints, hide the version, lock the login form. Two details get mentioned less often, and a surprising number of live sites still get both wrong years after launch. They are the security keys and salts in your config file, and the table prefix on your database. Neither is dramatic. Both are quiet leftovers from the day the site was installed, and both are worth a few minutes of attention.

What makes them interesting is that they are not the kind of thing you can clean up with a button without consequences. Get them wrong and you log everyone out or break a database query. So they are worth understanding rather than rushing. Here is what each one actually does, why it matters, and how to handle it without breaking your morning.

What keys and salts are doing in the background

Open wp-config.php and you will find a block of eight constants with names like AUTH_KEY and NONCE_SALT. These are your security keys and salts. They are not passwords you ever type. They are long random strings WordPress mixes into the way it hashes the cookies and session tokens that keep people logged in. The randomness is the point: it makes those stored authentication values much harder to forge or reverse.

When the values are strong and unique to your site, an attacker who somehow gets hold of a session cookie still cannot easily turn it into a working login. When the values are weak or shared, that protection thins out. And there is one common way they end up weak: they were never set in the first place.

The placeholder problem

WordPress ships wp-config.php with the salt block already present, filled with obvious placeholder text like put your unique phrase here. The installer is supposed to replace it, and the official one-click install usually does. But sites built from a manual config, copied from another install, restored from an old template, or set up before the automatic fill existed often still carry those placeholders, or a set of salts copied verbatim from somewhere public. A placeholder is the opposite of random. It is the most predictable value possible.

This is exactly why RecapWP flags Security keys/salts not set as a Medium-severity finding. It checks whether your keys and salts are still sitting at their placeholder values, and if they are, it tells you. The remedy is to generate a fresh, unique set, which strengthens the hashing those cookies and sessions rely on.

The wp_ prefix nobody bothered to change

Every WordPress install stores its data in a set of database tables, and every table name starts with a prefix. By default that prefix is wp_, so you get wp_posts, wp_users, wp_options, and the rest. The vast majority of sites on the internet are running on exactly that default.

This one is a smaller concern, which is why RecapWP rates Default database table prefix as Low severity rather than something louder. The default does not open a hole on its own. The issue is purely predictability. Some automated attacks, the kind that fire blind SQL at thousands of sites hoping one of them is misconfigured, assume the table names they are targeting. A non-default prefix will not stop a determined or skilled attacker who can read your schema anyway. What it does is raise the bar slightly for the dumb, high-volume automation that relies on everything being named the same. It is an obscurity measure, and a modest one, but obscurity that costs you nothing is still worth having.

A predictable default is not a vulnerability by itself. It is just one less thing an attacker has to figure out, and security is mostly the accumulation of small things an attacker has to figure out.

Why neither of these gets changed for you

RecapWP applies a fix for plenty of findings, where the change is a known configuration edit with a predictable result. These two are deliberately not on that list. Both are detect-only, and the reason is the same in spirit for each: the change is disruptive in a way that should never happen without you choosing the moment.

Rotating your keys and salts immediately invalidates every existing session. The instant the new values take effect, everyone who was logged in, including you, gets logged out and has to sign in again. That is harmless if you expect it and an alarming surprise if you do not, especially on a busy site or a membership store mid-checkout.

Changing the table prefix is more involved still. It is not a config edit; it touches the database itself. Every table has to be renamed and the new prefix recorded inside the wp_options table and the usermeta keys, all of which have to line up exactly. A half-finished prefix change leaves a site that cannot find its own data. That is a deliberate maintenance task, run with care and a current backup, not something a plugin should flip while you are looking the other way.

So RecapWP does what a good auditor should: it surfaces both clearly, explains the severity, and hands the decision to you. The value is in knowing. Most site owners have no idea their salts are still placeholders or that their prefix is the default until something points it out.

Doing both deliberately, with a backup

When you decide to act, treat each as a small planned job rather than a reflex.

For keys and salts, take a backup of wp-config.php first, generate a fresh set from the official WordPress secret-key service, and paste them in to replace the placeholder block, one constant for one constant. Save, and you are done. Everyone will be logged out, which is the expected outcome, so pick a quiet window and warn anyone who needs to know. This is also a worthwhile move any time you suspect a session may have leaked, since it instantly retires every cookie that was valid a moment ago.

For the table prefix, the order that matters is backup first, always, then the rename, then verify the site loads and you can still log in before you walk away. Most people do this once, at setup or during a migration, using a tool or their host's database utilities, and never touch it again. If your site is already live and running fine, there is no urgency to it. It is a Low-severity finding precisely because the cost of leaving it slightly outweighs the small risk of having it. Handle it on your own schedule.

The thread running through both is the same one that runs through all of hardening. None of it is urgent until the day it is, and the only way to know which of these leftovers is sitting in your own config is to look. Run a scan, read your findings worst-first, and you will see exactly where your keys, your salts, and your prefix stand, alongside everything else the site quietly forgot to tidy up.