HackerTube.dev

Single Point of Failure: The (Fictional) Day Google Forgot To Check Passwords

Tom Scott · 2.4M views · 2014-01-16 · 13:05

Open on YouTube ↗

If playback is restricted in your region, try opening the original video. Use Mark watched to add it to your marked videos.

Overview

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.

On Hacker News

HN commenters cite it as the canonical thought experiment whenever authentication failures, account compromises or Google outages come up.

Recommended by 2 HN people across 2 months · HN mentions 2018–2023

Topics

Security & hackingDocumentaries & storytelling
Search by tags
single point of failurepasswordsgooglefictionsecurity

What people said

richardwhiuk · 2023-05 · Recommendation

Single Point of Failure: The (Fictional) Day Google Forgot To Check Passwords - [VIDEO] is another, different topic, but still worth watching.

Read the original HN comment ↗
zaxomi · 2018-10 · Recommendation

When YouTube comes back up again, I can recommend Tom Scott with "Single Point of Failure: The (Fictional) Day Google Forgot To Check Passwords" [VIDEO]

Read the original HN comment ↗
iso1631 · 2022-04 · Reference

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

Read the original HN comment ↗

Sources

Video by Tom Scott, played through YouTube.

Data and selection notes

HN summaries and labels may contain AI errors. HN dates refer to discussions, not video publication.

HN Library: HackerTube export (2026-10-31) and open-index/hacker-news. Upstream summaries and classifications may contain AI errors.

Views, duration and playback status refresh separately from the published catalog. When an update fails, existing data remains visible.

Selection checks
  • SaaS & AI candidates: Topic keywords do not match
  • Editor-approved picks: Editorial review is required

Rule matches identify candidates. They do not guarantee video quality or financial results.

About the library and its sources