A common word with a year on the end is still a common password
Our sign-up refused a short list of common passwords, exactly as written. Nobody types them exactly: they add a year, a row of digits or a symbol. The check now finds the word underneath, and leaves passphrases alone.
· 3 min read
When we tested Rutba’s shared sign-in against production, one of the first things we tried was a bad password. The sign-up form accepted password1234.
It was not that there was no check. There was one, and it did what it said: it refused a list of the most common passwords, exactly as written. The trouble is that nobody types the list exactly. They type a word from it with a year on the end, a run of digits, an exclamation mark, or a zero where the o was — which is exactly why those passwords are on every attacker’s list too.
Checking for the word, not the string
The check now looks underneath. A password is refused as too common when, ignoring capital letters and undoing the usual letter-for-symbol swaps, it is one of these:
- A common word with only digits and symbols around it — or that word repeated.
Password2026!ispassword. So isp4ssw0rd. - A keyboard run, like the top row of letters.
- A sequence — every character one step from the last, up or down.
- One character repeated.
The swaps undone are the ones people actually use: 0 for o, 1 for i, 3 for e, 4 for a, 5 for s, 7 for t, @ for a, and an exclamation mark for i. The words are the ones common-password lists are built on — and our own brand names, because a password built on the name of the site you are signing up to is the first thing anybody guesses.
Nobody types the list’s exact entries. They type a listed word with a year on the end.
What it leaves alone
It does not add composition rules. There is no “must contain a capital, a digit and a symbol”, because those rules are what produce Password1! in the first place. A long passphrase of ordinary words is fine. A mixed password is fine. A password from a password manager is fine. The check refuses only passwords built on something guessable, and everything else is governed by length.
Where it applies
Everywhere a password is set on Rutba’s shared sign-in — which, since one sign-in covers every Rutba site, means one check for all of them:
- Creating an account.
- Setting a password while confirming your email address.
- Resetting a forgotten password.
- Changing your password while signed in.
An existing password that would now be refused is not locked out: the check runs when a password is chosen, not when one is used. And choosing one ends the sessions it should: a reset signs the account out everywhere, and a change signs out every session except the one that made it.
