A Quiet Sunday, Then an Amber Report
I run a small, private website for my family. It is where we share photos and plans, and only family members can sign in. Like everything else I look after, it is watched by automated agents that send me a short security report every morning and every evening.
On Sunday, November 1st, the morning report was green: nothing to see. The evening report came back amber. It said someone had tried to sign in to the family site fourteen times, and failed every time.
Fourteen failed sign-ins sounds alarming. The detail that mattered more was the timing: all fourteen happened within three seconds. No person types that fast.
What It Actually Was
At first glance it looks like someone guessing passwords. It was not. The "usernames" it tried were things like 1', 1" and 1'). Those odd quote marks and brackets are the web equivalent of jiggling a lock. They are designed to confuse a website that stores its data in a certain kind of database, in the hope that it slips up and lets the visitor in, or reveals something it should not.
It did the same thing to a part of each request most people never see: the label a browser sends to say which browser it is. That is the signature of an automated vulnerability scanner, a program that tries every input it can find. Tools like this sweep across huge numbers of websites every day. Nothing suggested my family was singled out.
| What it looked like | What it really was |
|---|---|
| Fourteen failed sign-ins | An automated scanner testing the sign-in form |
| Strange usernames full of quotes and brackets | Lock-picking characters aimed at a database |
| A visitor from London | A rented server; the location says little about who was behind it |
| An attack on my family | A broad, automated sweep that left after about a minute and has not been back |
Did Anything Get In?
No. Every attempt failed, and the site's own records show no successful sign-in from that visitor. The reasons are worth spelling out, because they are the parts that were built well:
- There was nothing for those tricks to work on. The site does not use the kind of database those characters are meant to confuse. The lock it was trying to pick was not on this door.
- Passwords are never stored as passwords. The site keeps only a scrambled fingerprint of each one, made deliberately slow to work backwards from.
- The error message gives nothing away. A wrong username and a wrong password get exactly the same reply, so a visitor cannot tell which part was wrong.
- The report itself was safe. The odd characters showed up in my security report as plain text. They could not do anything there.
The Weak Spots It Revealed
"Nothing got in" is not the end of the job. The more useful question is: what would have happened if this had been a determined attacker instead of a quick sweep? Reading the site's sign-in code with that question in mind turned up three things.
1. The doorman's notepad was too slow. The site already had a rule: too many wrong tries from one place, and you are locked out for a while. But it kept count the way a doorman might on a notepad that takes a moment to update. A burst of attempts all arriving in the same instant could each see the old count and walk past. That is how fourteen attempts arrived in three seconds without tripping it.
2. There was a side door. The site can be reached at its proper address, but also at a second, technical address the hosting service provides. Any protection added at the front door would not have covered the side door.
3. The site answered some wrong guesses too quickly. Even with identical error messages, a wrong username was rejected almost instantly, while a real username with a wrong password took a few thousandths of a second longer. To a patient attacker with a stopwatch, that difference quietly reveals which usernames exist.
What I Changed
- A bouncer at the front gate. A new rule now runs at the hosting service's edge, before a request ever reaches the site. It counts instantly and reliably: after a handful of sign-in attempts in a few seconds, that visitor is turned away. The site's own slower counter is still there behind it, for anyone who tries more patiently.
- The side door now leads to the front door. Anyone arriving at the technical address is sent straight to the real one, where the bouncer is standing. The one exception is the private feed my security agents read, which only works with a secret key.
- Every wrong guess takes the same time. An unknown username now goes through the same checking work as a real one, so the stopwatch trick no longer reveals anything.
Checking My Own Work
I do not consider a fix finished until it has been checked twice: once by a second reviewer, and once for real.
A second AI reviewer read the changes before they went live and caught two things. The first was a sloppy match that could, in theory, have redirected visitors it was never meant to touch. The second was more practical: the way I sent people from the side door to the front door would have quietly dropped a sign-in that was already in progress. Both were fixed before release.
Then I tripped the alarm on purpose. With the new protection live, I sent a rapid burst of deliberately wrong sign-ins from my own network, using an obviously fake name so the test could never be mistaken for an attack later.
Lessons Learned
- Read the details before reacting. "Fourteen failed sign-ins" sounded like a password attack. The timing and the odd usernames told the real story.
- "Nothing got in" is the start of the review, not the end. A harmless probe is a free rehearsal for a serious one.
- A speed bump is not a gate. Protection that can be outrun by speed needs something faster in front of it.
- Check every door, not just the front one. The weak spot is often a second way in that nobody thinks about.
- Test the alarm. A protection you have never seen trigger is a protection you are only hoping works.
What's Next
The morning and evening reports will keep watching the family site the same way. If a probe like this comes back, it will now be stopped at the gate within seconds, and the report will show it. I bring the same routine to the websites I look after for others: slow down, read the details, check every door, and test the fix.
Interested in the Details?
If you run a small website and want to know how it would hold up to a knock like this, I am happy to talk it through.
- Email, [email protected]
- LinkedIn, MFranklin, LLC