How Do Passwords Work? The System Should Never Know Yours

A cryptographic hash function takes input of any length and produces a fixed-length output, with three properties that matter: the same input always gives the same output, a tiny change in input changes the output completely, and finding an input that produces a given output is computationally infeasible. Storing the hash rather than the password means an attacker who steals the database does not immediately have anyone's credentials. That is the theory, and it fails in practice for a specific reason: people choose predictable passwords, so an attacker can hash every word in a dictionary and every common variation and compare the results against the stolen list, which is a guessing attack rather than a reversal. Precomputed tables of hashes, called rainbow tables, made this fast enough to be trivial, which is why the next two defences exist.

Two additions turn a weak scheme into a strong one:

• •A salt, a random value generated per user, stored alongside the hash and combined with the password before hashing. It does not need to be secret. Its purpose is to make every user's hash unique even when passwords are identical, which destroys precomputed tables and forces an attacker to attack each account separately
• •A deliberately slow function, since ordinary hashes are designed to be fast and speed helps the attacker far more than the defender. Purpose-built password functions including bcrypt, scrypt and Argon2 apply many rounds of work with a tunable cost factor, so a single check takes a fraction of a second and a billion guesses take centuries
• •Memory-hard designs such as Argon2 and scrypt additionally require substantial memory per guess, which specifically frustrates attackers using graphics processors and custom hardware that can perform enormous numbers of simple operations in parallel
• •A pepper, a secret value stored separately from the database, so that stealing the database alone is not enough
• •The recommended settings are published and updated, and the cost factor is expected to be increased over time as hardware improves

The rules most people were taught came from a 2003 document by Bill Burr at the American standards institute, recommending forced complexity and regular expiry. He publicly regretted them in 2017, and the current guidance from the same institution reverses most of it. Forcing an uppercase letter, a digit and a symbol produces predictable transformations, since people capitalise the first letter, append a digit and substitute an exclamation mark for the final character, which attackers model directly. Mandatory expiry every ninety days produces sequential passwords ending in incrementing numbers and encourages writing them down, and the evidence is that it reduces security overall. Password hints and security questions are worse than useless, since the answers are frequently public. The current recommendations are: require a minimum length and allow very long passphrases, check candidate passwords against lists of ones known to be breached, permit and encourage password managers including pasting, and do not force periodic change without evidence of compromise.

Length beats complexity because the number of possible passwords grows exponentially with length and only linearly with the size of the character set, which is why a long passphrase of ordinary words outperforms a short string of symbols, a point made memorably by a well-known web comic. Uniqueness matters more than either, because the commonest attack is not guessing but credential stuffing: taking username and password pairs from one breached site and trying them everywhere else, which works because password reuse is close to universal. A password manager solves both, generating long random unique passwords and removing the need to remember any of them, and the objection that it places all credentials in one place is answered by the fact that the alternative in practice is reuse. Two-factor authentication is the largest single improvement available, and the factors differ in strength: an authenticator application generating time-based codes is far better than a text message, which can be intercepted by persuading a mobile operator to transfer a number, and a hardware security key is better still because it verifies the site's identity and therefore cannot be phished.

The replacement now being deployed removes the shared secret entirely. Passkeys, built on the public key standards developed by the FIDO Alliance and the web consortium, generate a key pair on the user's device, keep the private half in secure hardware and register the public half with the site. Logging in means the site sends a challenge, the device signs it after the user authenticates locally with a fingerprint, face or device PIN, and the site verifies the signature. Nothing secret is transmitted, so there is nothing to steal from the server, nothing to reuse across sites and nothing a phishing page can capture, since the signature is bound to the real site's domain. The system is supported by the major platforms and browsers and is being adopted gradually, with the transition slowed by account recovery, by devices that cannot sync and by the practical difficulty of removing a fallback that would reintroduce the original weakness.

Systems store a one-way hash rather than a password, and the defence works only with a per-user random salt, which defeats precomputed tables, and a deliberately slow memory-hard function such as Argon2, which makes mass guessing impractical. The old rules about forced symbols and ninety-day expiry were withdrawn by the person who wrote them, because they produce predictable patterns. Length and uniqueness matter more than complexity, credential stuffing is the commonest attack, and passkeys remove the shared secret entirely.