Single Passwords Are Bullshit
I am annoyed. I am, specifically, annoyed that in the wake of a breach of extremely sensitive information, the excuse offered is that “oh, it was just the breach of a single password” as though this was somehow an unavoidable thing, a small and unimportant matter.
This is a bullshit excuse in 2025. And I want to explain why I think that.
The Old World
When we started Doing Computers (you know, 60 years since New Zealand banks started computerising, to put it in some perspective), we treated the question of “who should be able to access this data” as something to be solved on an application-by-application basis. Applications would store their users’ data somewhere, probably a database (IBM invented IMS in 1966; relational databases that are used for most applications now began appearing in the 1970s).
In this world, applications have a user and password that lets them access the database. The application can see everything – if there’s data for Rodger, Violet, and Tom, then the application code can read it all. The application code has to enforce the rules around Rodger only being able to access Rodger’s data.
This is a serious problem.
If the application code has a small bug in it, and it doesn’t enforce the rules correctly, suddenly Rodger is reading Tom’s data. If the application configuration doesn’t store the credentials securely – and even now in the year 2025 you would be dismayed how many applications store this sort of sensitive material as an unencrypted file on a disk — then anyone who gets a copy has full access to Rodger, Violet, and Tom’s data.
Tickets, please
Back in 1989 some smart people came up with the foundation for a solution to this problem: Kerberos. I’m not going to attempt to explain the ins and outs of Kerberos because frankly I’m not that clever, but one of the things you can do with Kerberos (and Microsoft started making easy to do when it made Kerberos the foundation of Active Directory with Windows 2000) is to minimise this vulnerability. In the case of Kerberos, that’s via tickets.
When you log into a computer or application that uses Kerberos, you get given a ticket that confirms you are who you say you are (or at least that you know my username and password); when Rodger logs into his Kerberos-enabled laptop, he gets a ticket. If he goes to use an application that understands Kerberos, the application will look up the ticket and say “sure, that’s Rodger, he’s allowed to use this application”.
So far this looks like the pre-1989 flow, right? Ah, but here’s where you can make things better. When the application connects to the database, the database can check the ticket again. So instead of letting the application see all the data, and hoping the application doesn’t fuck anything up, it looks at the ticket and says “oh, the application is being used by Rodger? In that case, have Rodger’s data and no-one else’s”.
This is a very solid way of dealing with sensitive data. Even if the application has bugs, it’s very hard for the bugs to be bad enough to disclose the wrong data (not impossible, because computers); it doesn’t matter if the application’s login to the database is stolen, because the database won’t let you see any data without a ticket. And stealing Kerberos tickets is reasonably difficult; moreover, to steal all of Rodger, Tom, and Violet’s data you’d need three tickets, not one login.
In 2025 this is an idea called “Identity Pass-Through”.
Everything Old is New Again
While Kerberos is actually really widely deployed – approximately every corporate network in the world uses it via ActiveDirectory — this technique is not as commonly used as you’d expect, given that everything you need to do it has been around for 35 years (or 25 if you want it to be as easy as writing .NET apps).
Not only that, but when people started developing web applications in the late nineties they pretty much re-invented user management from scratch, site by site (I would throw shade but I have committed my share of those sins so I guess I should say “we re-invented”); one reason for that is that persuading people to use Kerberos over the Internet is a non-starter, even for things like accessing their banking or healthcare records.
But there are smart people who want to make these things as easy as they can be, and so modern, Internet and developer-friendly solutions for identity pass-through have been reinvented with OAuth, for example. The mechanism is different – the tickets don’t look the same — but the principles are identical. You log in, the application checks your JWT, passes it to the database server (or the API endpoint or the mess of other ways we now store and access data), the database server re-validates it, Rodger can only see Rodger’s data because the database is configured to only allow that. If you want to steal Rodger’s data, you have to steal Rodger’s identity. If you want to steal Rodger’s data and Violet’s data and Tom’s data you have to steal all three identities.
Grotesque Negligence
This is an incredibly well-solved problem. It has been solved for a very long time. The libraries you need to take advantage of it in an application, the configuration options in databases, these are all readily available.
No, you aren’t going to go to the effort of implementing this in your hobby blog or self-hosted webmail server because getting all the relevant bits hanging together correctly and making sure you have a good-quality identity provider is not an easy task, but if you are being paid money to look after people’s money or health information or similarly sensitive data, you ought to have a very good explanation for why you’re still doing security like it’s 19-fucking-eighty-eight.
