In Why Trust Is Hard we established that digital trust breaks down into authentication, integrity, and confidentiality, and that authentication comes first, because nothing else works if you don’t know who you’re talking to. This post is about the mechanics of that question. How do you prove you are who you say you are?
Three things you can know
Every authentication system in history is built on the same three foundations. Security textbooks call them factors, and they are:
- Something you know, a password, a PIN, the name of your first pet.
- Something you have, a key, a card, a phone, a hardware token.
- Something you are, a fingerprint, your face, the pattern of your iris.
Each has strengths and weaknesses. Something you know can be guessed or stolen without you noticing. Something you have can be lost or physically stolen, but at least you’ll notice it’s gone. Something you are can’t be lost or forgotten, but it also can’t be changed, if someone copies your fingerprint, you can’t get a new one.
Multi-factor authentication combines two or more of these. Your bank card (something you have) plus your PIN (something you know) is two-factor. Your phone (something you have) unlocking with your face (something you are) is two-factor. The idea is simple: compromising one factor is easy; compromising two independent factors simultaneously is much harder.
This framework is ancient. Medieval castles used it. The gate guard recognised your face (something you are) and demanded the password (something you know). A messenger carrying sealed orders presented the seal (something you have) and identified the sender (something you know). The factors are the same. The implementation has changed.
Passports and the invention of portable identity
The passport is arguably the most successful identity document in history, and its evolution tells you a lot about the problems of identity at scale.
The word itself comes from the French passe-port, permission to pass through a port (gate). Early passports were letters from a ruler requesting safe passage for the bearer. They described the traveller’s physical appearance in words, height, hair colour, eye colour, distinguishing marks, because photographs didn’t exist. King Henry V of England is sometimes credited with the earliest English passport, around 1414.
For centuries, passports were optional, inconsistent, and rarely checked. The great era of relatively free movement in Europe was the 19th century, you could travel from London to Constantinople without showing a single document. It was World War I that changed this. Governments needed to control borders, track military-age men, and prevent espionage. The modern passport, standardised, photograph-bearing, nationally issued, is a product of wartime paranoia that never got rolled back.
The International Civil Aviation Organization (ICAO) standardised the machine-readable passport (MRP) in 1980 with Document 9303. That strip of text at the bottom of your passport’s photo page, two lines of letters, numbers, and chevrons, contains your name, nationality, date of birth, passport number, and a check digit. The check digit is computed from the other fields using a simple algorithm; if any character is altered, the check digit won’t match, and the scanner will flag it. It’s a basic integrity check, not encryption.
Since 2006, most countries have been issuing biometric passports (e-passports) with an embedded RFID chip. The chip stores a digital copy of your photo, your biographical data, and in many cases your fingerprints. All of this is digitally signed by the issuing country’s certificate authority, a cryptographic chain of trust that lets the receiving country verify the data hasn’t been tampered with, without needing to contact the issuing country in real time.
This is important. A border guard in Tokyo can verify that your Australian passport chip data is genuine by checking the digital signature against Australia’s public key, which is distributed through the ICAO Public Key Directory (PKD). The guard doesn’t need to phone Canberra. The mathematics does the verification. We’ll dig into how digital signatures work in How Encryption Works.
But the passport system also illustrates the limits of identity verification. The passport proves that a government attests that this document was issued to a person with these characteristics. It doesn’t prove you’re that person, it proves you have their passport. If someone steals your passport and looks enough like your photo, the passport will vouch for them. The biometric chip makes this harder (the fingerprint data can be checked against a live scan), but the fundamental weakness remains: the document is a proxy for identity, not identity itself.
Passwords: the worst system except for all the others
The password is the most widely used authentication mechanism in the world, and its history is instructive.
Fernando Corbato, a computer scientist at MIT, is generally credited with inventing the computer password in 1961 for the Compatible Time-Sharing System (CTSS). The system had multiple users sharing a single computer, and each user needed their own files. Corbato’s solution was simple: store each user’s password in a file, and check it at login. The passwords were stored in plaintext, unencrypted, readable by anyone with access to the file.
In 1962, a PhD student named Allan Scherr wanted more than his four-hour allocation of computer time. He discovered that the password file could be printed out using an offline request, and did so. He got every user’s password. He later described this as possibly the first computer password theft in history. (Scherr confessed this publicly at a 25th anniversary celebration for the CTSS, decades later.)
The response to this kind of attack led to password hashing. Instead of storing your password, the system stores the hash of your password, a one-way mathematical transformation that produces a fixed-length string. When you log in, the system hashes what you type and compares it to the stored hash. If they match, you’re in. If someone steals the hash file, they can see the hashes but can’t easily reverse them to get the passwords.
Robert Morris Sr. (father of the Robert Morris who later created the Morris Worm, one of the first internet worms) implemented password hashing with a technique called salting for Unix in the late 1970s. A salt is a random value added to your password before hashing, so two users with the same password get different hashes. Without salting, an attacker who cracks one hash instantly knows every account using that password. With salting, each hash must be cracked individually.
The evolution continued: DES-based crypt, MD5, SHA-1, bcrypt (1999), scrypt (2009), Argon2 (2015, winner of the Password Hashing Competition). Each generation is deliberately slower to compute, because the defender only needs to check one password at a time while the attacker needs to try millions. Making each check slower costs the defender milliseconds and costs the attacker years.
Despite all this engineering, passwords remain terrible for reasons that are human:
People choose bad passwords. The security researcher Mark Burnett analysed millions of leaked passwords in his 2011 book Perfect Passwords and found that “123456” and “password” consistently topped the list. The 2023 NordPass analysis of leaked credential databases found the same two passwords still leading the pack, joined by “123456789” and “qwerty.” Roughly 1% of all passwords in the dataset could be guessed in a single attempt.
People reuse passwords. A 2019 Google/Harris Poll survey found that 65% of people reuse the same password across multiple sites. This means a breach at one site compromises accounts at every other site where the same credentials were used, an attack known as credential stuffing. The 2012 LinkedIn breach exposed 6.5 million password hashes; those same email-and-password pairs were then tried against thousands of other services, and a depressing number of them worked.
Phishing works. A 2024 Verizon Data Breach Investigations Report found that phishing and pretexting (social engineering) accounted for the vast majority of initial access in confirmed breaches. No amount of password complexity helps if the user types the password into a fake login page.
The uncomfortable conclusion is that passwords are a broken authentication factor. They’re “something you know,” but in practice they’re “something you know and frequently tell to the wrong person.”
Biometrics: your body as your password
Biometric authentication uses physical characteristics, fingerprints, facial geometry, iris patterns, voice, as identity proof. The appeal is obvious: you can’t forget your fingerprint, and you can’t leave your face at home.
Fingerprint identification has been used since the late 19th century. Sir Francis Galton (a problematic figure for many reasons, but relevant here) published Finger Prints in 1892, establishing that fingerprint patterns are unique and persistent throughout life. Sir Edward Henry developed the classification system that police forces adopted worldwide. The FBI’s fingerprint database, IAFIS, holds over 150 million sets of prints.
Digital fingerprint scanners work by capturing the pattern of ridges and valleys on your fingertip and converting it to a mathematical representation, a template. The template is compared against stored templates, not the raw image. This matters for security: if someone steals your fingerprint template, they can’t reconstruct your actual fingerprint from it (in theory, the boundary between theory and practice here is disturbingly thin).
Facial recognition has improved dramatically with deep learning. Modern systems like Apple’s Face ID project over 30,000 infrared dots onto your face, building a 3D depth map that’s resistant to flat photographs. Apple claims a false acceptance rate of 1 in 1,000,000 for Face ID, compared to 1 in 50,000 for Touch ID fingerprints. But the technology has well-documented bias problems. A 2019 NIST study (Face Recognition Vendor Test, Part 3) found that many commercial facial recognition algorithms had significantly higher false positive rates for Black and East Asian faces than for white faces, in some cases by a factor of 10 to 100.
The fundamental problem with biometrics is irrevocability. If your password is stolen, you change it. If your private key is compromised, you revoke it and generate a new one. If your fingerprint is stolen, and fingerprints can be lifted from surfaces, photographed from a distance (a Japanese researcher demonstrated extracting fingerprints from peace-sign selfies in 2017), or obtained from data breaches, you can’t get a new fingerprint. The 2015 breach of the US Office of Personnel Management exposed the fingerprint records of 5.6 million government employees and contractors. Those fingerprints are compromised forever.
This is why biometrics work best as a local authentication factor, unlocking a device you physically possess, rather than as a remote credential transmitted over a network. Your phone stores your fingerprint template in a secure enclave and never transmits it. That’s a different security model from, say, a database of fingerprints checked over the internet.
Certificates and public keys
When a website says it’s your bank, how do you know? You can’t check its fingerprint. You can’t look at its passport. The answer is digital certificates, a technology we’ll explore in depth in How Certificates Work, but the identity implications are worth previewing here.
A digital certificate is a signed statement: “I, a trusted authority, certify that this public key belongs to this entity.” The trusted authority is a certificate authority (CA). Your browser ships with a list of root CAs it trusts, roughly 50 to 150 of them, depending on the browser and operating system. When you connect to your bank’s website, the bank presents a certificate signed by one of these authorities (or by an intermediate authority that chains back to a root). Your browser checks the signature, checks the chain, and if everything validates, shows you the padlock icon.
The trust model here is hierarchical. You trust your browser vendor. Your browser vendor trusts the root CAs. The root CAs trust the intermediate CAs. The intermediate CAs certify the websites. If any link in that chain fails, if a CA issues a fraudulent certificate, if a CA’s private key is compromised, if your browser’s trust store is tampered with, the whole thing collapses.
And it has collapsed. In 2011, the Dutch CA DigiNotar was compromised, and the attacker issued fraudulent certificates for google.com, used to intercept the Gmail traffic of Iranian dissidents. DigiNotar was subsequently removed from all browser trust stores and went bankrupt. In 2015, the Chinese CA CNNIC issued an intermediate certificate to a company that used it to intercept HTTPS traffic. Google and Mozilla revoked trust in CNNIC’s certificates. These aren’t hypothetical risks; they’re history.
OAuth, SAML, and delegated identity
Sometimes you don’t want to prove who you are to a website directly. You want to say “Google knows who I am, ask them.” This is delegated authentication, and it’s how “Log in with Google/Apple/Facebook” buttons work.
OAuth 2.0 (RFC 6749, published 2012) is the protocol behind most of these flows. Despite its ubiquity, OAuth is technically an authorisation protocol, not an authentication protocol, it was designed to answer “what is this app allowed to do?” rather than “who is this person?” The authentication layer was bolted on later as OpenID Connect (OIDC), which adds an identity token to the OAuth flow.
The flow works roughly like this: you click “Log in with Google” on some website. The website redirects you to Google. You authenticate with Google directly (Google sees your password; the website never does). Google sends you back to the website with a token that proves you authenticated successfully. The website trusts Google’s assertion.
SAML (Security Assertion Markup Language) does something similar but is older (2002), more complex, XML-based, and primarily used in enterprise environments. If you’ve ever logged into your company’s internal tools and been magically logged in to everything else, that’s probably SAML single sign-on.
Both OAuth and SAML have the same fundamental property: they separate the identity provider (the entity that knows who you are) from the service provider (the entity you’re trying to use). This is elegant because it reduces the number of places your credentials are stored. Instead of giving your password to a hundred different websites, you give it to one identity provider, and the others trust that provider’s assertions.
The risk is concentration. If your Google account is compromised, every service that uses “Log in with Google” is compromised. Single sign-on is single sign-compromise. The trade-off is considered worthwhile because Google (or Microsoft, or Apple) invests far more in account security than the average website could.
Passkeys: the end of passwords?
The newest development in identity is passkeys, built on the FIDO2/WebAuthn standard (first published as a W3C Recommendation in 2019, with Level 2 in 2021).
The idea is beautifully simple. When you register with a service, your device generates a unique cryptographic key pair, a public key and a private key. The public key goes to the service. The private key stays on your device, locked behind biometric authentication (fingerprint, face) or a device PIN. When you log in, the service sends a challenge, your device signs it with the private key (after you authenticate locally with your fingerprint or face), and the service verifies the signature with the public key.
No password is ever transmitted. No password is ever stored on the server. There’s nothing to phish, even if you’re tricked into visiting a fake website, the cryptographic challenge is bound to the real website’s domain, and the fake site gets a response it can’t use. Credential stuffing is impossible because there are no credentials to stuff. The private key never leaves your device.
Apple, Google, and Microsoft all began supporting passkeys in their ecosystems in 2022-2023, with the ability to sync passkeys across devices via their respective cloud services. The syncing is encrypted end-to-end. Apple, for instance, syncs passkeys through iCloud Keychain, which is encrypted with keys derived from your device passcode that Apple never sees.
As of early 2026, passkey adoption is growing but still modest. GitHub, Amazon, PayPal, Best Buy, and many others support them. The challenge is the chicken-and-egg problem: users won’t set up passkeys until sites support them, and sites won’t prioritise passkeys until users demand them. But the technology is sound, the user experience is better than passwords (touch your fingerprint instead of remembering “Tr0ub4dor&3”), and the security properties are genuinely superior.
Authentication vs authorisation
Before we move on, it’s worth nailing down a distinction that trips up even experienced developers.
Authentication answers: “Who are you?” Authorisation answers: “What are you allowed to do?”
They’re different questions with different mechanisms. Authenticating you as “Craig Webster” doesn’t tell a system whether Craig Webster is allowed to delete the production database. That’s an authorisation decision, and it’s handled by access control lists, role-based access control (RBAC), attribute-based access control (ABAC), and other mechanisms that map identities to permissions.
The confusion arises because the two often happen together. You log in (authentication) and immediately see your dashboard (authorisation determined what’s on it). But they’re independent systems, and treating them as one is a reliable way to build insecure software.
A real-world analogy: your passport authenticates you at the border (you are who you claim to be). Your visa authorises you (you’re allowed to enter the country, for this long, for this purpose). Having a valid passport doesn’t mean you can enter any country. Having a valid login doesn’t mean you can access any resource.
The identity gap
Despite all of these technologies, a fundamental problem remains: digital identity is not human identity.
When you authenticate with a password, you’re proving you know a secret. When you authenticate with a fingerprint, you’re proving you possess a specific body part. When you authenticate with a certificate, you’re proving you control a private key. None of these things is you. They’re proxies for you. And proxies can be shared, stolen, coerced, or faked.
There’s no way to prove, mathematically or mechanically, that the human being pressing the keys is the same human being who created the account. There’s only the accumulation of evidence, this device, this biometric, this credential, this location, this behaviour pattern, that makes the alternative (impersonation) increasingly implausible.
This is why modern authentication systems are moving toward continuous authentication, not just checking your identity at login, but monitoring your behaviour throughout a session. Typing patterns, mouse movements, access patterns, geographic location. If your account suddenly starts behaving differently, logging in from a new country, accessing files it never touches, typing at a different speed, the system raises an alert, even though the login credentials were correct.
We’ve been proving identity with increasingly sophisticated technology for thousands of years, from wax seals to elliptic curve cryptography. But we’re still solving the same fundamental problem the village gate guard solved with a question and a hard stare: you say you’re allowed in. Convince me.
Next, we go deeper into the mathematical foundation underneath all of this. How Encryption Works covers the cryptography that makes digital identity, integrity, and confidentiality possible, from Caesar’s army to the algorithms protecting your bank account right now.