Site Hardening · Part 2
A password change is not an audit
After a compromise, almost everyone does the same thing: change the WordPress password, maybe the hosting password, and call it done.
That covers two keys. A working website has a dozen or more, held by people, by software and by services you set up years ago and forgot. Some of them outrank the ones you changed. Hardening starts with knowing every key that exists, who holds it, and what it opens.
Part 1 walked the chain above your server — registrar, DNS, recovery email. This part walks everything that can log in.
The question is scope, not strength
The instinct is to ask whether a password is strong. The better question is how much each key opens.
From the case file. The key that let the intruders in was not weak and was never guessed. It was a file-transfer login, stored by the site-building software in a project file on the server, and it was scoped to the root of the hosting account. One key, every site in the account. That is why a compromise that began on one small site ended up publishing spam on five domains.
So for every key you find, write down two things: who holds it and what it reaches. A key that reaches one folder is a problem. A key that reaches everything is the problem.
The inventory
Work through these in order. Each one is a place a key can live without you thinking about it.
The hosting account. Its own login, plus any additional users it lets you create. Check for sub-users, delegated access, and anyone your host gave access to for support.
File transfer accounts. Most hosts let you create several, each with its own home folder. List every one, and check what folder it starts in. An account that starts at the top of your hosting space can write to every site in it.
The database. Its username and password live in your configuration file, and the database server has its own list of which machines may connect. Part 10 of the investigation series covers the setting that let any computer on the internet try.
WordPress users. Every account, not just the administrators. Look at when each was registered and what email it uses. In this case the intruders left five accounts behind over five months, and one of them was simply named admin, with a password to match.
Application passwords. Separate keys that let software sign in as a user without a second factor. They sit at the bottom of each user’s profile page, and almost nobody knows they exist.
Search Console. Every user on every property, and every verification method. What Search Console knows after a hack explains why an intruder who verifies ownership can keep reading your data after a rebuild.
Service accounts and API keys. The ones software uses. If you have ever connected a tool to Google, a backup service or a security scanner, there is a key for it somewhere — often in a file.
The DNS provider. Whoever logs in here controls where your domain points and where your email goes. It usually has its own login, separate from both registrar and host.
The keys software holds
People remember the logins they type. They forget the ones they gave to a program.
From the case file. The owner’s own Search Console property carries three users: his own account, a second account for the business, and a Google Cloud service account holding Owner — set up so his tools could submit pages for indexing. All three are legitimate. But the service account is the most powerful user on the property, and its key is a file on a computer somewhere.
That isn’t a reason to remove it. It is a reason to know exactly where that file lives, who can read it, and to treat it like a password — because to Google, it is one.
The same goes for anything that ever held access during the fighting. A security plugin used during the cleanup in this case was deactivated months ago; its service was still contacting the site long afterwards. Turning software off does not always revoke what it was given. Remove the connection at the service’s end too.
The keys that sign every login
One set of keys never appears on any list of users, because nobody types them. WordPress keeps eight long random values in its configuration file — the security keys and salts. They sign the cookie your browser holds after you log in. As long as they stay the same, every logged-in session stays valid.
That makes them the one key that ends sessions. Changing a password doesn’t log anyone out. Replacing the salts logs out everyone at once — you, every editor, and anyone who got in with a stolen session. WordPress publishes a generator that produces a fresh set; you paste it over the old eight lines, and it’s done.
What they don’t do matters as much. Salts guard sessions, not files. Someone who can still write to your server doesn’t need a session at all.
From the case file. The salts on the compromised account were changed at least five times during the fighting. Every change worked exactly as designed, and none of them stopped anything, because the intruders’ access was at the file level. Part 10 of the investigation series explains why salts are step five of a cleanup, not step one.
For hardening, the useful habits are simple. Change them once the door is closed, so the reset actually sticks. Change them after anyone leaves — a developer, an employee, a support session you granted. And change them on a schedule, a few times a year, the same way you would any other key. It costs one login.
And keep them where they belong: in the configuration file, which is exactly why that file must never be readable from the web, never copied into a public backup, and never left behind as an old copy like wp-config.php.bak. Anyone who reads the salts can forge a login cookie without knowing a single password.
No shared passwords
The second rule is just as short: no password is used in two places. Not across sites, not across services, not between the hosting account and the email that recovers it.
A unique password wouldn’t have stopped the first break-in in this case — that came from a stored login, not a guessed one. What reuse does is multiply. One password read from one file, or leaked from one unrelated website’s breach, becomes the key to every account that shares it. A single compromise turns into several, and each one looks like a separate attack.
Nobody can remember dozens of long, unique passwords, and nobody should try. A password manager generates and holds them; you remember one strong passphrase, protected with two-factor of its own. It also answers the inventory question from earlier in this article, because every key you hold ends up in one list.
And “shared” means people as well as places. A login handed to a developer, a friend or a support technician is no longer yours alone. Give them their own account where the service allows it, and remove it when the work is done.
Two-factor on everything
The owner’s rule after this compromise is short: two-factor on everything that offers it. Not just WordPress — the email account, the registrar, the DNS provider, the hosting account, Search Console, and every service that holds a key to the site.
The order of importance is the chain from Part 1. Email first, because it resets everything else. Then registrar and DNS, which outrank the server. Then hosting, which outranks the site. WordPress last — and in his case, not at all, because the dashboard is reached only through the hosting account.
Three details decide whether it actually holds:
- Where the second factor goes. An authenticator app or a hardware key is stronger than a text message, which can be redirected by anyone who talks a phone company into moving your number.
- Where the recovery codes live. Every service gives you backup codes for when the phone is lost. Print them or keep them offline. Codes saved in the same email account they protect are no backup at all.
- What it doesn’t cover. Plain file transfer has no second factor and never will — which is why the answer there is SFTP, not two-factor. Application passwords skip it by design, and turning it on doesn’t end sessions that already exist. Part 10 of the investigation series covers all three holes.
Rotate what existed during the compromise
Here is the rule that keeps this manageable: any key that existed while the intruder was inside gets replaced. Not the ones you suspect. All of them.
You can’t prove which ones were read. A configuration file, a project file or a backup archive can expose a whole set of keys at once, and none of that leaves a trace in a log. Replacing a key costs minutes. Proving it was never seen costs more than you have.
Two orders matter. Rotate from the outside in — email and registrar first, then DNS and hosting, then the site — so that a key you haven’t changed yet can’t be used to reset one you just did. And do it after the entry point is closed, which the cleanup order in Part 10 sets out. Rotating keys while the door is still open just hands out new ones.
Fewer keys is the real fix
An audit tells you what exists. The lasting improvement is having less of it.
After this compromise, the owner changed how he reaches his sites in two ways, and between them they removed most of what an intruder could steal.
Files move over SFTP only. The old file-transfer login travelled in plain text. The one he uses now is encrypted in transit, so there is nothing for anyone on the network to read.
There is no WordPress login in use. He doesn’t sign in through the WordPress login page at all — he goes through his hosting company’s account, which opens the WordPress dashboard directly. The public login page refuses anyone who isn’t him. A WordPress password nobody types can’t be phished, guessed, reused on another site, or intercepted.
The trade is honest: the hosting login now opens every site, so it carries all the weight. That login gets the strongest password, two-factor, and a recovery email that is paid for and controlled — which is exactly where Part 1 started.
What this costs
An evening with a list. Every login, every holder, every scope. Replace everything that was alive during the compromise, remove what nobody needs, and make the keys that remain fewer and stronger.
It won’t feel like security work, because nothing on the screen changes. It is the part that decides whether the next person who gets in needs a vulnerability — or just a key you forgot you handed out.
Most sites have more keys than their owners can list. A recovery review maps every account that can still reach yours and shows which ones outlived the compromise.
Start a Recovery ReviewPaid assessment · scope agreed up front
Back: Hardening Starts With What You Own, Not What You Install
Next: Let the Edge Hold the Door: Cloudflare in Front of WordPress
Hub: Site Hardening Blog Series
ProVAE builds and recovers websites in Douglas, Georgia, serving South Georgia.