Single Point of Failure: The (Fictional) Day Google Forgot To Check Passwords on HackerTube: recommended by 2 Hacker News commenters across 2 separate months, 2018–2023.
talk · evergreen
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.
“It's basically the scenario Tom Scott laid out about what would happen if Google stopped checking passwords”
8 Hacker News comments link this video. Each one links back to its thread.
Single Point of Failure: The (Fictional) Day Google Forgot To Check Passwords - ▶ this video is another, different topic, but still worth watching.
in “Welcome to Life: the singularity, ruined by lawyers by Tom Scott” · View on HN
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
in “Ask HN: YouTube down?” · View on HN
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
in “Bearer tokens are just awful” · View on HN
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]
in “Today Google is turning on tracking for many users that previously turned it off” · View on HN
Just reading the title it sounded very much like "Single Point of Failure: The (Fictional) Day Google Forgot To Check Passwords": ▶ this video
in “Google broke a conditional statement that verifies passwords on Chrome OS” · View on HN
It's basically the scenario Tom Scott laid out about what would happen if Google stopped checking passwords... except it happened to Parler. ▶ this video
in “Parler Databases Disclosed” · View on HN
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...)
in “Google outage – resolved” · View on HN
Even worse could be an RCE vuln in Chrome at the same time that the google.com search page gets compromised... Also I think the post you're talking about is this video by Tom Scott: ▶ this video
in “Ask HN: What if gmail was compromised?” · View on HN