Tom Scott
2 HN recommenders · recommended in 8 months, 2018–2023
13:05 · 2.4M views · Jan 16, 2014
Tom Scott performs a fictional story at GeekyConf about the day Google accidentally stops checking passwords, letting anyone into any account. It works as a parable about how a single point of failure in login can unravel everything built on it.
HN commenters cite it as the canonical thought experiment whenever authentication failures, account compromises or Google outages come up.
8 comments from Hacker News
When YouTube comes back up again, I can recommend Tom Scott with "Single Point of Failure: The (Fictional) Day Google Forgot To Check Passwords" this video
Single Point of Failure: The (Fictional) Day Google Forgot To Check Passwords - this video is another, different topic, but still worth watching.
So I have a service using openid and I use google to authenticate the person logging in. I do that, then that's done. Now I could simply issue a session cookie, or a permament cookie, to the client so we never have to use google again. Or I could make it so that cookie lasts 10 minutes before reauthentication. I can use a refresh token which means they don't need to reauthenticate but if google expires the connection (disabled user etc), I expire mine. Either way, that's my decision as the person running my site, and it's the clients decision as the person running the client to decide whether to send the blob, or to share that blob with other clients. The only information I know is that somebody authenticated with google at a specific time and I had proof of that, I have no control over what happens to that blob. Google has nothing to do with what I or the client do with the information. You're right that I can't audit the third party (google, microsoft, etc), but I don't pretend I can. Google could simply change their password checking to "if (true)", that's google's business. If I'm worried about the third party authenticator then I shouldn't use it, and I should roll my own. (There was an early Tom Scott video imagining a world where google just says "yes" to passwords[0]) I have an internal read-only blog site using our corporate openid service to ensure that someone accesses the site. Once they authenticate, I allow them access for 30 days before forcing a reauthenticati
Google's entire business hinges on user privacy from everyone other than Google. If, tomorrow, either this Account Security scenario happened[0] or this South Park website happened[1] (everyone's internet history searchably by anyone), and it was done at the incompetence of Google, they would crumble overnight. They might recover within a year or two if they release a statement and fix it within a few hours or something, but it would be devastating and they would have to kiss their entire Google Cloud business (encompassing Cloud Platform and Workspace) goodbye. Once more, even for their ad business, they don't sell that data, they target based off of it. They would lose their competitive data advantage overnight if someone could pay them $100 per-user for every user's full advertising profile since they could then go behind Google's back and out-header-bid Google with lower margins. 0: this video 1: [LINK]
As many comments in this thread have mentioned, the crash seems to happen when when logged in; youtube and other services seem to work when don't send the session cookie. This suggests something very fundamental related to user account/sessions is failing... Did Maria Christensen make a mistake when adding "return true;"? (This is a joke referencing Tom Scott's 2014 parable[1] about the danger of designing a system with a single point of failure . Tom's tells the fictional tale of a high level employee at Google adding "return true;" to the global "handleLogin()" function.) [1] this video (you might need to open this link in a private window...)