The History of Passwords and Authentication

Zusammenfassung

The password is the oldest and most universally despised form of computer authentication. It was introduced on MIT’s CTSS time-sharing system in 1961, and the first password breach occurred shortly thereafter when a researcher printed the password file in plain text. In the sixty-plus years since, the security industry has invented hashing, salting, two-factor authentication, hardware security keys, and passkeys — each in response to a new attack that rendered the previous defense inadequate. The history of authentication is the history of an arms race between defenders who understand that secrets are hard for humans to maintain and attackers who exploit that understanding with increasing sophistication.

The First Passwords: CTSS and the First Breach

MIT’s Compatible Time-Sharing System (CTSS), developed starting in 1961, was one of the first systems to use passwords. The design decision was straightforward: multiple users shared a single mainframe, and each needed private file storage. A password associated with each account provided the separation.

The first recorded password breach occurred on CTSS in 1962. Allan Scherr, a PhD student who wanted more than his allotted four hours of machine time per week, noticed that the CTSS password file was stored as a regular file accessible to programs with the right permissions. He printed it. He obtained other users’ passwords and could use their time allocations. The mechanism of the breach — accessing a stored password file — remains one of the most common attack vectors sixty years later.

Early systems stored passwords in plain text. If an attacker obtained the password file, they immediately knew every user’s password. The solution was hashing: instead of storing the password itself, store a one-way cryptographic hash of the password. When a user logs in, hash what they typed and compare it to the stored hash. An attacker who obtains the hash file cannot easily reverse the hashes to obtain the passwords.

Unix password hashing used crypt(), based on DES (the Data Encryption Standard), introduced in the early 1970s. The system added a salt — a random value stored alongside the hash — to prevent rainbow table attacks: precomputed tables of hash values for common passwords. With a salt, each password’s hash is unique even if two users choose the same password, because the salt is different. Computing a rainbow table for every possible salt is computationally infeasible.

The Password Problem: Human Cognition vs. Security Requirements

The fundamental problem with passwords is that they require humans to memorize high-entropy random strings — and humans are terrible at this. Actual human password behavior, studied at scale through breached password datasets, is consistent: people choose short passwords, use common words, append numbers (often “1” or “123”), and reuse the same passwords across multiple services.

The 2012 LinkedIn breach, which exposed 6.5 million hashed passwords, provided researchers with the largest dataset of real human passwords at the time. Analysis found that “password”, “123456”, “linkedin”, “sunshine”, and variations thereof were among the most common. The breach was doubly instructive: LinkedIn had stored passwords using unsalted SHA-1 hashes, a poor choice that made cracking trivial with modern hardware. Within hours of the dataset’s publication, tools had cracked approximately 1 million of the passwords.

Password strength requirements — “must contain uppercase, lowercase, number, and special character” — were established as policy guidance by NIST in 2003 and became ubiquitous. They are counterproductive: they train users to create predictable patterns (Password1! satisfies all requirements) rather than genuinely random strings, and they increase the cognitive burden of passwords in ways that drive reuse. NIST reversed this guidance in 2017, recommending against mandatory complexity requirements and in favor of longer passwords and checking against breach databases.

Password managers — software that generates and stores random passwords, filling them into web forms automatically — are the correct technical solution to the human cognition problem. Adoption remains incomplete: estimates suggest 20–30% of internet users use password managers as of the mid-2020s. The remaining 70–80% reuse passwords, creating what security professionals call “credential stuffing” vulnerability: a breach of one service provides attackers with credentials that work on many others.

The Credential Stuffing Economy

When a service is breached and passwords are exposed, attackers test those credentials against hundreds of other services automatically. Services with “reused” credentials fall like dominoes. The scale is staggering: Have I Been Pwned (HIBP), Troy Hunt’s breach notification service, contained over 12 billion breached accounts as of 2024. The existence of this dataset, freely searchable, allows users to check whether their credentials have been exposed — and allows services to prevent users from creating accounts with known-breached passwords.

Two-Factor Authentication

The fundamental limit of password authentication is that a password is “something you know” — and knowledge can be stolen, guessed, or phished. Multi-factor authentication adds a second factor from a different category:

Something you have: A physical device (phone, hardware security key)
Something you are: Biometric (fingerprint, face, iris)

SMS-based 2FA (a one-time code sent to your phone via text) became the most widely deployed second factor in the 2010s because it required no additional hardware — users already had phones. SMS 2FA is significantly better than password-only authentication; it is also significantly weaker than hardware-based 2FA because SMS messages can be intercepted through SIM swapping (social engineering a carrier to transfer a victim’s phone number to an attacker-controlled SIM) and SS7 attacks (exploiting vulnerabilities in the global telephone signaling network that was designed without security assumptions).

Time-based One-Time Passwords (TOTP) — the codes generated by apps like Google Authenticator — improved on SMS 2FA by using a shared secret and a time algorithm rather than SMS infrastructure. TOTP codes are generated on-device and not transmitted over the vulnerable phone network. They are susceptible to real-time phishing: an attacker who tricks a user into entering their TOTP code can relay it to the actual site within the 30-second validity window.

Hardware security keys (FIDO U2F, later FIDO2/WebAuthn), developed by the FIDO Alliance starting in 2013, provided the strongest widely available second factor. A hardware key (like YubiKey) performs a cryptographic challenge-response over USB or NFC: the site sends a challenge, the key signs it with a private key stored on the hardware, and the site verifies the signature. The signed challenge includes the site’s domain, making phishing impossible — a signed response for https://login.microsoft.com cannot be replayed at https://login-microsoft.com. Google deployed WebAuthn across its workforce in 2017 and reported zero successful phishing attacks against employees thereafter.

OAuth and Federated Identity

OAuth (2006, originally by Blaine Cook at Twitter and others) created a standard for delegated authorization: a user could authorize one application to access their account on another service without giving the application their password. The classic use case: “Log in with Google” — Google authenticates the user and provides an authorization token to the third-party application, which can then make API calls on the user’s behalf without ever seeing the password.

OAuth 2.0 (2012) is the standard authorization protocol for web applications. OpenID Connect (OIDC), built on OAuth 2.0, added identity information: the user’s identity is asserted by the identity provider (Google, Apple, Microsoft, GitHub) rather than managed by each individual application.

The “Sign in with Apple” feature (2019) required all iOS App Store apps that offered third-party login (Google, Facebook) to also offer Sign in with Apple — and introduced the option to hide the user’s email address, forwarding messages through a relay. This addressed privacy concerns about sign-in data being shared with identity providers.

Passkeys: The End of Passwords?

Passkeys (the consumer brand name for FIDO2/WebAuthn credentials) were introduced as a standard by the FIDO Alliance and supported natively by Apple (iOS 16, macOS Ventura, September 2022), Google (Android 14, 2023), and Microsoft (Windows Hello). The concept: replace passwords entirely with a cryptographic keypair, where the private key never leaves the user’s device and the public key is registered with the service.

Authentication with a passkey works as follows: the user touches the fingerprint sensor or looks at the Face ID camera; the device unlocks the stored private key; the private key signs a challenge from the service; the service verifies the signature against the stored public key. No password is transmitted or stored by the service. Phishing is impossible (the domain is part of the challenge). Credential stuffing is impossible (there is no password to stuff).

Major services — Google, Apple, GitHub, PayPal, KAYAK, and others — implemented passkey support between 2022 and 2024. The FIDO Alliance reported that passkey creation had reached hundreds of millions by 2024. Full transition from passwords to passkeys remained incomplete: users accustomed to passwords were slow to adopt the new mechanism, and the cross-device synchronization story (moving passkeys between an iPhone and an Android device) required cloud backup that some security-conscious users found concerning.

The sixty-year problem of password authentication appeared to have a cryptographic solution — one that had taken two decades of standards work, three hardware generations, and several major breaches to deploy at scale.