One password for every site: one breach, every site

One of your websites gets hacked. A few hours later every other site on the same server is hacked too, including the ones nobody had touched. You change the password on the first site and assume that is the end of it, and it is not, because the same password was in use everywhere.

That is what happened on a server we inherited. One value had been used as the database password for every site, as the administrator login on several of them, and as the file-transfer login. It had been convenient for years. The cost was the whole estate at once: one attacker, one file read, every site compromised in the same window.

What was actually going on

The password was not weak. It was never guessed and never broken. The attacker read it, once, out of the configuration file of the first site, which every website has to be able to read in order to run at all. Making the password longer would have changed nothing.

A password answers two questions. How hard is it to get without permission? And once someone has it, what does it open? Strength only addresses the first. On a server where the website has to read its own password from a file, the first question is settled the moment an attacker can run code inside that site. After that, the only protection left is what the password opens, and a shared password opens everything.

Nobody chooses a shared password because they think it is safe. It makes several ordinary tasks easier: adding a site needs one less value to record, debugging is faster because you already know the password, and bulk jobs across sites need no lookup table. The saving is small, daily and visible. The cost is huge, rare and invisible until it arrives all at once.

Reuse also switches off the remedy. A password for one site can be changed on a Tuesday afternoon, with one site’s downtime as the worst outcome. A shared one can only be changed across every site at the same moment, which means risking every site at once, so nobody does it. The value from a document written three years earlier was still live.

What we changed

Every database password on the server is now different for each site. The shared value is gone from the configuration files, and its old name is recorded as dead so nobody brings the habit back. Administrator logins are per site, and the file-transfer login no longer shares a value with anything.

Remote login to the server moved to keys only. Password login was switched off entirely, not just discouraged, so a stolen or reused password cannot be used to get in at that layer. A console password still exists for recovery through the hosting provider, and the documentation states that it is only that, because the danger here was somebody finding an old value that looked valid and assuming it worked everywhere.

For anyone inheriting an estate with this pattern, the order matters. First, set up a way in that does not depend on any password that might be compromised, and confirm it works before touching anything else. Second, list every place the shared value appears: website configuration, deployment scripts, backup jobs, monitoring, scheduled tasks, a spreadsheet, and at least one document nobody remembers writing. Third, change it one site at a time, so a mistake hits one site. Fourth, and most important on a server that has already been compromised: changing passwords before the attacker’s access has been removed is a race you lose. They can read each new value the moment you write it.

What it did not fix

The setup has one key for remote login and no password fallback. If that key is lost, recovery goes through the hosting provider’s rescue console. The right answer is a second trusted key held somewhere separate. We recorded this plainly rather than calling the setup finished.

Separate passwords do not stop a site being hacked. They limit what a hacked site can open. The other half of the same incident, where the sites ran as one user on one server, is a separate problem with a separate fix.

The pattern, for anyone with more than one website or system

Pick any one password in your business. List everything it opens. If the list has more than one entry, you share a blast radius, whether or not you think of it that way.

Then ask when it was last changed, and whether you could change it this afternoon. If the honest answer is “not without coordinating everything”, it is shared in practice regardless of how it looks in the settings.

Separate passwords cost a few minutes each to set up. Shared ones cost the whole estate, once, on a day you do not get to pick.

Where this ends up

Taking over a set of sites that has grown this way, and separating them so one failure stays one failure, is the work described under enterprise modernisation.