The question every access decision quietly assumes
The previous guides in this rung handed you a powerful machinery for deciding who may do what. The access-control list on a file says "alice may read, bob may write." The principle of least privilege says give each subject the smallest set of rights it needs. But read those rules again and notice the word they all lean on: alice, bob, each subject. Every one of them takes for granted that the system already knows who is sitting at the keyboard. That assumption is exactly what this guide is about.
It helps to keep three separate ideas apart, because beginners blur them constantly. Identification is your claim — you type the username alice, announcing who you say you are. Authentication is the system testing that claim — proving the person typing really is alice. Only after that does authorization kick in: now that the system is convinced you are alice, it consults the access-control list to decide what alice may do. Authentication is the second step, the gatekeeper that makes the third step meaningful. An access matrix with perfect rules is worthless if anyone can simply claim to be alice and be believed.
Why must the operating system itself care? Because authentication is the moment a human being is bound to a subject inside the kernel — a user identity that the protection mechanisms will trust from then on. Get this wrong and every later check is built on sand. That is why login lives close to the most trusted code in the system, and why the machinery that verifies you is counted as part of the trusted computing base: if the login path can be fooled, nothing above it can be sound.
Three things: what you know, have, and are
There are really only three raw materials out of which any proof of identity can be built, and it is worth naming them because every method you will ever meet is one of these or a mix. The first is something you know — a password, a PIN, the answer to a secret question. The second is something you have — a physical token, a phone, a hardware key, a smart card you must possess. The third is something you are — a biometric: your fingerprint, your face, the pattern of your iris. Each rests on a different kind of secret, and each fails in a different way.
Be honest about each one's weakness, because no single factor is strong. Something you know can be guessed, phished, reused across sites, or read off a sticky note. Something you have can be stolen or lost — and then the thief is you, as far as the machine can tell. Something you are sounds unbeatable but is the most quietly dangerous of all: a biometric is not a secret (you leave fingerprints on every glass you touch, your face is on every photo), it cannot be changed once compromised (you get ten fingers, then you are out), and it is fuzzy — it must match approximately, which means it can both wrongly reject the real you and wrongly accept an impostor.
The password problem: a secret you must verify but never keep
Passwords are the workhorse of authentication, so it is worth seeing the real cleverness in how an operating system handles them. Here is the trap a naive system falls into: to check your password at login, surely it must compare what you type against the password it has on file — so it stores everyone's passwords in a table. But that table is now the single richest prize on the machine. One leak — a stolen disk, a backup gone astray, a database dumped by an attacker — and every account is open at once. The very thing that proves identity has become the thing that destroys it. The deep idea of password storage is to resolve this paradox: verify a secret you do not actually keep.
The tool that makes this possible is a cryptographic hash function. Picture a one-way meat grinder: you can feed any input in and get a fixed-size scrambled output (the hash), but you cannot run the grinder backwards to recover the input from the output. Two more properties make it useful here. The same input always grinds to the same output, so the result is repeatable; and it is computationally infeasible to find two different inputs that grind to the same output, or to find any input that produces a given output. So the system never stores your password at all — it stores only the hash. At login it grinds whatever you typed and checks whether that hash matches the stored one. A thief who steals the table gets a pile of hashes, and the grinder will not run backwards.
But hashing alone is not enough, and the gap is instructive. If everyone who picks the password "dragon" ends up with the identical hash, an attacker need not reverse the grinder at all. They can grind millions of common passwords once, in advance, build a giant lookup table from hash back to password, and then simply read off every account whose stored hash appears in it. They can also see at a glance that two users share a password. The fix is a salt: a unique random value generated per user, mixed in before hashing, and stored in the clear right next to the hash. Now alice's "dragon" and bob's "dragon" grind to two completely different hashes, the precomputed table is worthless because it would need a separate version for every possible salt, and the attacker is forced back to attacking each account one painful guess at a time.
STORING a new password CHECKING a login attempt ---------------------- ------------------------ salt = random() look up stored (salt, H) H = hash(salt + password) h = hash(salt + typed) store (salt, H) <- no password accept if h == H the table holds only salt + hash; the password itself is never kept
Slowing the attacker down, and the OS's wider use of crypto
Salting stops precomputation, but a determined attacker with a stolen table can still guess. They take a leaked hash, grind candidate passwords one by one with that user's salt, and wait for a match — an offline attack, run on their own hardware as fast as it will go. A general-purpose hash function is dangerously fast here: modern machines can try billions of guesses a second. So good systems deliberately use a slow password hash — functions like bcrypt, scrypt, or Argon2 that are built to be expensive on purpose, often by repeating the work thousands of times and demanding lots of memory. A login that costs you a tenth of a second is invisible; multiplied across billions of guesses, it turns an afternoon's cracking into centuries.
Step back and you will see that this same cryptographic toolkit shows up all over the operating system, not just at the login prompt. The hash function that verifies passwords is the same kind of building block that lets the OS check a downloaded update has not been tampered with (does its hash match the publisher's signed value?), that lets the kernel confirm a driver was signed by someone it trusts before loading it, and that underpins encrypting a whole disk so that a stolen laptop yields only meaningless bytes. Cryptography is how the OS extends its protection beyond the running machine — out to data at rest and code arriving from elsewhere — where the hardware boundaries it normally relies on no longer reach.
Walking one login from keypress to trusted identity
Let us trace a single password login end to end, so the pieces lock together. Imagine alice sitting down and typing her username and password. Notice as we go how much of this is about keeping the secret from ever lingering where it could be stolen, and how the result is not a message but a change in what the kernel believes about this session.
- Alice types alice and her password. The keystrokes travel up through the input path to the login program, and crucially the password is never echoed to the screen and is held only briefly in memory.
- The system looks up the stored record for the user alice and reads out two things: her unique salt and the hash that was computed when she last set her password. It does not — because it cannot — read out her actual password.
- It mixes the freshly typed password with that salt and runs the slow password-hash function over the combination, deliberately spending a fraction of a second on the work.
- It compares the hash it just computed against the stored hash. If they differ, the attempt is rejected (and a real system adds a small delay and a failure count so an attacker cannot machine-gun guesses). If they match, the proof has succeeded.
- Now the binding happens: the kernel attaches alice's user identity to this session, and from this moment every process she starts inherits that identity. Subsequent access checks — the file permission bits, the access-control lists — finally have a trustworthy subject to test against, and authorization can do its job.
Two reflections close this out. First, see how authentication is the hinge between a human and the protection machinery: before step five there is only a claim, after it there is a kernel-trusted identity that everything downstream depends on. Second, notice how careful the whole dance is to never let the real secret sit anywhere an attacker could grab it — typed but not echoed, hashed at once, never stored in the clear. That same paranoid spirit is exactly what the final guide of this rung is built on. Once an attacker is already running code on the machine, how do modern defenses — stack canaries, address randomization, secure boot — fight back? Authentication keeps the wrong people out; those defenses assume someone got in anyway.