Blog · a series
Signing in
One account for every Rutba site, and the parts of that nobody thinks about until one of them goes wrong: which realm checks your password, the second factor and where it lives, the last hop a browser is right to refuse, and where signing in should leave you.
10 parts · about 37 minutes to read them all
Part 1 · 3 min read
One sign-in for every Rutba site, and why it asks for your address first
Six Rutba sites used to disagree about whether you were signed in, and two of them collected passwords of their own. Now there is one front door, and since 24 September it is the one sign-in for the whole suite, the workspaces included.
Part 2 · 3 min read
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.
Part 3 · 3 min read
The lookup before your password, and why it cannot recognise you
Sign in at Rutba and the first thing that happens is a lookup on your address, not a password box. It reads only the domain, so it answers the same for an address that does not exist. And it was quietly doing nothing for weeks before we noticed.
Part 4 · 4 min read
One place for your second factor, and a code you can scan
Turning on two-factor used to mean typing a thirty-two character secret by hand. It is a code you scan now, or a button on a phone, and the factor itself lives in one store rather than two, which is the part that keeps a settings page honest.
Part 5 · 3 min read
The password was right. The browser refused the last hop
A sign-in that looked like a wrong password was a security header doing its job too well: it allowed the form but not the page the form lands on. The fix was to build that rule from the list of places a sign-in is already allowed to end.
Part 6 · 3 min read
Where a sign-in should leave you: the app you hold, not a lobby
Signing in used to send everybody to the customer console, including people who hold no customer account. It now sends you to the one app you can actually open, and when you hold several, a page lays them out by organisation, with a link on every one.
Part 7 · 5 min read
One sign-in for the whole suite, and an organisation that stays chosen
Since 24 September, Rutba’s workspaces no longer ask for a password of their own. You sign in once, the organisation you chose stays chosen until you switch, nothing about it travels in a link, and signing out anywhere signs you out everywhere.
Part 8 · 3 min read
A suffix is not an allow-list: the frames behind one sign-in
One sign-in works by small hidden pages that tell an app who is signed in. The first version trusted any address ending in our domains, which included shops running their merchants’ own code. Review caught it before it reached production.
Part 9 · 3 min read
The sign-in service no longer has a database of its own
Rutba’s sign-in kept its own database: sessions, keys, second-factor challenges, an audit trail, and a second copy of everybody. Since 21 September it keeps nothing. Every record it needs lives in the one backend that already held people.
Part 10 · 7 min read
A reset belongs where the sign-in is, even for somebody Rutba has never met
From 26 September, staff reset their password at Rutba’s sign-in and a shop’s customers reset at the shop, never across. Somebody only their company’s workspace knows can now reset at Rutba too, and every address still gets the same answer.
