Passwords were invented by accident. Here’s what it took to fix them

My phone was on airplane mode: no signal, no Wi-Fi, nothing. I still needed to log into my bank.

I opened the authenticator app anyway, more out of habit than hope, and there it was: six digits, ticking down, exactly as if nothing were wrong. I typed them in. Voila! It worked.

That shouldn't be possible. Somewhere, a server belonging to a bank I've never visited was expecting the same six digits, at the same second, from a piece of software that hadn't spoken to it in weeks. No signal was exchanged. No request went out, and yet both sides agreed instantly that I was exactly who I claimed to be.

It all started with an email I didn't expect

A while back, I got a notification email from a platform I frequently use: the email address on your account has just been changed. But I haven't requested anything.

What almost certainly happened is duller and scarier than a targeted hack: a password I'd used years ago, on some completely unrelated site, had leaked in a breach I never even heard about. Somewhere, an automated script had quietly tried that same email and password combination against hundreds of other services (a technique security teams call __credential stuffing) and found one where it still worked, logged in, and immediately changed the recovery email so I couldn't get back in first.

I hadn't been hacked, exactly. I'd been found in a list.

That list is bigger than most people imagine. In 2012, LinkedIn was breached, and roughly 6.5 million password hashes turned up on a Russian hacking forum. At the time, the company believed that was the extent of it. Four years later, in 2016, it emerged that the real number was 117 million accounts; the passwords had been stored as unsalted SHA-1 hashes, a method that lets attackers crack them almost as fast as they can be downloaded, and a hacker using the handle "Peace" put the full set up for sale for the price of five bitcoin. For four years, well over a hundred million people had no idea their passwords were already circulating.

And LinkedIn 2012 is a rounding error next to what exists now. In July 2024, researchers uncovered a single file, nicknamed "RockYou2024", containing nearly 10 billion unique plaintext passwords compiled from thousands of separate breaches going back over a decade. Named after an even older 2009 breach that first proved storing passwords in plain, unencrypted text was a catastrophe waiting to happen, "RockYou2024" is less a hack than an inheritance: a running archive of nearly every password ever leaked, quietly available to anyone willing to point automated software at it.

Here's the part that makes this personal rather than abstract: your email is the master key to almost everything else you own online. Password reset flows nearly always run through it. An attacker doesn't need to guess your bank password if they can get into your inbox and simply ask for your bank to send a new one. One old, reused, leaked password is often the only weak link required to pull that thread.

The password was an afterthought, and it broke almost immediately

In the early 1960s, MIT had one very large, very expensive computer and many researchers who all wanted to use it. The solution was a new system called CTSS (Compatible Time-Sharing System), which let multiple people work on the same machine by taking turns in tiny slices of time.

There was just one problem. Everyone could see everyone else's files.

Fernando Corbató, one of the researchers building CTSS, wasn't trying to invent digital security. He just wanted people to stop poking around in each other's work. So in 1961, he added something almost embarrassingly simple: a password prompt. Type the right word, get your own files. Type the wrong one, get nothing.

It was, by his own account, never meant to be serious protection, just enough to stop casual snooping. Decades later, looking at what the world had built on top of his afterthought, he offered his own verdict on it.

"A nightmare" — Fernando Corbató, inventor of the computer password

He wasn't exaggerating. Within about two years, a CTSS bug printed out the system's entire password file for anyone to read. One graduate student, Allen Scherr, later confessed he'd used exactly this kind of leak to keep accessing the system after his own privileges were revoked. The first password system on record was compromised almost as fast as it was built. That's the pattern that everything else in this story follows: someone invents a barrier, and someone else finds the gap in it almost immediately. The sixty years between Corbató's cafeteria-grade password and the six digits on your phone are really just an increasingly elaborate argument about where to put that gap next.

Proving you have something, not just that you know something

By the 1980s, a password alone clearly wasn't enough. Passwords could be guessed, shared, written on sticky notes, or simply intercepted. Corporations and governments needed a second layer: not something you knew, but something you physically had.

Kenneth Weiss: a human factors engineer who founded a company called Security Dynamics in 1984. His invention was almost comically unglamorous: a small plastic fob, about the size of a car key, with a tiny LCD screen that displayed a new string of digits every 60 seconds.

Something that made it clever was that every fob shipped from the factory with a unique secret number baked into it(its seed), and a synchronized internal clock. The company's server knew that same seed. So every minute, without any connection between the fob and the server, both sides could independently run the same calculation on the same secret and land on the same number.

This was the birth of real two-factor authentication: your password proved what you knew; the fob proved that you physically had it in your pocket. Weiss's invention, later known as RSA SecurID after his company was absorbed into RSA Security, ended up in the hands of defense contractors, banks, and eventually tens of millions of ordinary employees worldwide.

Weiss understood exactly what made the system fragile, and he said so, more than once, to his own colleagues:

"I would have to explain that that was grossly unnecessary." — Kenneth Weiss, on being asked, repeatedly, whether the token seeds should be centralized on corporate computer

He was talking about that one design decision that would matter more than any other.

The theft that broke the system

By 2011, RSA SecurID tokens were about as close to an industry standard as security hardware gets, which made it a spectacular target. In March of that year, RSA disclosed that attackers had broken into its systems and made off with information tied to its SecurID technology. What they'd actually taken wasn't some clever mathematical exploit: it was simpler and far more damaging. They'd stolen the seed database: the master list connecting every fob's serial number to its secret key. The exact thing Weiss had spent years insisting should never be centralized in one place.

With it, an attacker didn't need to guess anything or crack any encryption; they could simply generate the same "secret" number the real fob would generate at the same time and walk through the front door.

Two months later, defense contractor Lockheed Martin detected exactly this: intruders using stolen seed data, combined with a separately phished password, to gain access to its network as an authenticated employee. Lockheed shut down remote access company-wide and reset the network passwords of over 100,000 employees. RSA eventually offered to replace tens of millions of tokens.

The lesson wasn't that the math was weak. It was that the secret had to live somewhere, and wherever it lived became the real target. Every security system, no matter how elegant, has an address. Find the address, and the elegance stop mattering.

The fob gets swallowed by the phone.

While RSA was building an entire hardware business around a physical fob, a different kind of pressure was building at Google. In late 2009, the company disclosed that it had been hit by a sophisticated intrusion, later nicknamed "Operation Aurora", that targeted its internal systems and the accounts of human rights activists. It was the kind of wake-up call that makes "just use a stronger password" sound naive.

Google's answer, released in September 2010, was a free app: Google Authenticator. It did essentially the same trick as Weiss's $50 hardware fob:

• A shared secret
• A synchronized clock
• A fresh code every thirty seconds

Except it lived inside a device that a few billion people already carried in their pocket anyway. There was no fob to lose, no battery to die, no shipping cost to replace one that broke. You just installed an app.

Microsoft followed with its own version a few years later, and today Microsoft Authenticator does more than generate codes. It can send a simple push notification straight to your phone, asking you to approve or deny a sign-in with a single tap, no typing required. It's a smoother experience than reading six digits off a screen and retyping them somewhere else.

An entire hardware industry- key fobs, batteries, replacement logistics, shipping costs got folded into an icon on a homescreen. Nobody mourned it. Most people don't even remember it happened.

How does Authenticator actually work?

When you first set up an Authenticator app for an account, you scan a QR code. That single moment is the only time any secret ever gets exchanged. Hidden inside that QR code is a randomly generated string, the seed, and from that instant on, both your phone and the account's server privately store an identical copy of it. Neither one will ever need to tell the other anything again.

It is something like you and a friend agree on some secret number in person. Then you agree on a rule that every 30 seconds, you'll each independently run that secret number through the same math problem, using the current time as an ingredient.

The formal version of this idea is called TOTP (Time-based One-Time Password), standardized in a document called RFC 6238 in May 2011. It is an evolution of an earlier standard, HOTP, published in 2005, which used a counter that ticked up with each login instead of the actual time. The problem of synchronization faced by HOTP was later addressed by TOTP using a time counter.

What's actually happening inside those thirty seconds

The codes are generated using hash functions. A hash function takes an input of any length; it could be a word, sentence, or a long number, and produces a fixed-length output. SHA-256 hash function always produces a 256-bit (32-byte) output.

It is practically impossible to figure out the original input. They are also very sensitive: if you change just one character in the input, the output changes completely. These properties make hash functions ideal for security. But TOTP doesn't use SHA-250 alone. It uses it inside a construction called HMAC.

HMAC (hash-based message authentication code): a clever way to combine a secret key with a message using a hash function. The result generated is a short piece of data that proves both authenticity("it came from someone with the secret key") and integrity("the message was not changed").

The HMAC formula is straightforward: prepare the key by making sure it has the right length; combine the key with a constant called the inner pad using the XOR function; hash it together with the message; combine the key with the outer pad using the XOR function; and hash it together with the result from step 2.

The final output you get is a 256-bit string, or 64 hexadecimal characters. Now, to turn this into a short code, TOTP uses a process called dynamic truncation. It selects a portion of the output based on its last few digits, then interprets those bits as a number, and finally, it reduces the number by dividing it by 10⁶ and taking the remainder. The result is a six-digit number between 000000 and 999999.

1. Converting current time to time-based counter

T = | Current Unix Time - T0| / 30

2. The counter is then combined with the secrte key using HMAC-SHA256

HMAC-SHA256 (K, T) = SHA256 ((K XOR opad) || SHA256((K XOR ipad) || T))

3. HMAC output is truncated and converted into 6-digit number

TOTP = Truncate(HMAC-SHA256 (K, T)) mod 10⁶

where:
T0 = starting time, usually 0
K = secret key
T = time-based counter
ipad = inner pad
opad = outerpad
SHA256 = Hashing algorithm

1. Converting current time to time-based counter

T = | Current Unix Time - T0| / 30

2. The counter is then combined with the secrte key using HMAC-SHA256

HMAC-SHA256 (K, T) = SHA256 ((K XOR opad) || SHA256((K XOR ipad) || T))

3. HMAC output is truncated and converted into 6-digit number

TOTP = Truncate(HMAC-SHA256 (K, T)) mod 10⁶

where:
T0 = starting time, usually 0
K = secret key
T = time-based counter
ipad = inner pad
opad = outerpad
SHA256 = Hashing algorithm

Say your secret key is "SPIDERMAN" (in reality, it'd be a random string of bytes) and the current time counter is 1,000,000. Compute the HMAC-SHA256 of the secret and counter. This yields a 256-bit result, like 4a3b7f2c…(64 hexadecimal characters). Use the last few bits to choose an offset, then take 4 bytes starting from that offset. Convert those bytes into a number, say 123456789. Divide 123,456,789 by 10⁶ and take the remainder 456,789. Thus, your six-digit OTP is 456789.

Even the government stopped trusting text messages

TOTP has been overriding the older, more familiar kind of one-time password most people actually grew up with: the text-message code. An SMS OTP has no algorithm running on your device at all: it depends entirely on a message physically arriving over a mobile network whose cost is paid by the seller who opted for this service for their business and can be easily exploited through SIM swapping: an attacker convinces your mobile carrier, often through nothing more sophisticated than a phone call and some social engineering to move your number into a SIM card they control. From that point on, every "secure" code the bank texts you goes straight to them.

This risk got serious enough that the U.S National Institute of Standards and Technology- the body that writes the federal government's security guidelines- proposed deprecating SMS as an authentication method back in 2016, especially because of interception and SIM-swap risks. The final guidance softened slightly, but the direction has stayed the same: SMS-based codes are now formally treated as a restricted method, permitted only under stricter conditions, while app-generated TOTP codes carry no such warning label.

Does any of this actually work?

It's fair to ask, after all this history of broken passwords and stolen seed databases, whether any of it is actually worth the friction of pulling out your phone every time you log in.

In 2019, Google published a year-long study, run with researchers from New York University and UC San Diego, tracking real account hijacking attempts across its own user base. The results were about as clear as security research ever gets. A simple SMS code blocked 100% of automated bot attacks, 96% of bulk phishing campaigns, and 76% of targeted, hands-on attacks. On-device prompts and app-based codes did even better, blocking 100% of bots, 99% of bulk phishing, and 90% of targeted attacks.

Microsoft Security and Google Security also confirm that over 99.9% of compromised accounts did not have Multi-Factor Authentication(MFA) enabled.

When the fix becomes the exploit

Not every version of this second layer asks you to type anything. Plenty of corporate systems replaced the six — digit code with something even smoother: a single push notification that just says "Approve this sign-in?" Tap yes, and you're in.

That extra convenience turned out to be its own vulnerability. In September 2012, an attacker linked to the hacking group Lapsus$ bought a stolen Uber contractor's password off the dark web. MFA stood in the way, so the attacker simply triggered login attempt after login attempt, flooding the contractor's phone with dozens of approval prompts in a single night. Worn down, and then contacted directly over WhatsApp by someone posing as Uber's IT department and asked to "just approve the next one," the exhausted contractor finally tapped yes. That one tap gave the attacker access to Uber's internal Slack, cloud storage, and admin tools.

Security researchers now call this MFA fatigue, or push-bombing: the second factor doesn't get broken; it gets worn down. In the aftermath, much of the industry pushed toward "number matching," forcing the approving device to display a number the user has to match against their login screen, restoring a sliver of the deliberate friction that plain push approval had removed.

The pattern nobody points

Look at the whole chain, and something becomes obvious: nobody actually solved authentication. Everyone just relocated the argument.

A password lives in your head until someone leaks the file it's stored in. A hardware token moves the secret into your pocket until someone steals the seed database it came from. A phone app moves it again, into a device you're far less likely to lose than a fob, but now the target is your phone itself, the account recovery process behind it, and whichever cloud backup might sync your codes.

"Security is a process, not a product." — Bruce Schneier, Secrets and Lies (2000)

Every fix narrows the attack surface. None of them close it. The story of authentication isn't a story of problems being solved; it's a story of the same unsolved problem being handed off to a slightly harder target each time.

The one question this whole system never quite answers

There's a question every authenticator app quietly avoids until the exact moment you need it answered: what happens when you lose the phone?

Because the seed lives only on your device, dropping your phone in a lake doesn't just cost you a phone- it can lock you out of every account tied to it. Most services handle this with a set of one-time backup codes, generated once, meant to be written down or printed and kept somewhere that isn't your phone. Almost nobody does this. It's the same instinct that made Corbató's password an afterthought: the fix works perfectly right up until the one moment it's tested for real, and by then it's too late to prepare.

Some apps have started backing up your seeds to the cloud, encrypted, so a new phone can recover your old codes.

What happens when the six digits disappear

There's a reasonable chance the very thing we just talked about is already on its way out.

The industry's current push is towards passkeys-cryptographic keys generated and stored on your device itself, verified with your fingerprint or face, with no password and no six-digit code involved anywhere in the process. Apple, Google, and Microsoft have all been building toward a future where you never type a password again, let alone a rotating code.

If that future actually arrives, the authenticator app you just learned to admire may end up as a fifteen-year bridge technology- the SecurID fob's smarter descendant, but still just a stopover on the way to something else. Which means the six digits ticking down on your phone screen right now aren't the end of this story. They're the version of it we happened to grow with.

Sources:

1. First Computer Password Shaped Our Digital World, But Lost To History | Justinas Vainilavičius | Cybernews.
2. RockYou2024: 10 Billion Passwords from a 2012 Hack just got Posted Online | Vilius Petkauskas | Cybernews.
3. Stupid, Arrogant, and Greedy(Weiss on SecurID seed storage) | David Kearns.
4. RSA Security breach explained: why US defense programs could be compromised | David Cenciotti | TheAviationist.
5. Lockheed Martin Suffers Massive Cyberattack | Matthew J. Schwartz.
6. RSA Admits Security Tokens Hacked, Offers Replacements | Paul Wagenseil | NBC News.
7. Google is Making Your Account Vastly More Secure With Two-Step Authentication | Jason Kincaid | TechCrunch.
8. RFC 4226: HOTP: An HMAC-Based One-Time Password Algorithm — IETF (2005) | D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache, O.Ranen | RFC Editor.
9. RFC 6238: TOTP: Time-Based One-Time Password Algorithm — IETF (2011) | D. M'Raihi, S. Machani, M. Pei, J. Rydell | RFC Editor.
10. What is MFA Fatigue (Push Bombing)? | Ahona Rudra | SecurityBoulevard.

You'll also find other trusted sources linked throughout this piece.

Thank you for reading!

For more of me, find me on LinkedIn.