How Websites Store Passwords

Why websites should never store your actual password

If a website stored your password as plain text and was breached, an attacker would have your password immediately. Since most people reuse passwords, that one breach would cascade to every other account. Responsible websites solve this by storing a transformed version — a hash — instead. The transformation is one-way: from the hash alone, the original password cannot be recovered.

What a cryptographic hash is

A hash function takes any input and produces a fixed-length output — a string of characters that looks random. SHA-256, for example, always produces a 256-bit (64-character hex) output regardless of whether the input is one character or one million. The critical property is that the function is one-way: you can compute the hash from the password, but you cannot compute the password from the hash. The same input always produces the same output, but tiny changes in input produce completely different outputs.

The problem with simple hashing: rainbow tables

If every user who chooses "password123" gets the same hash, an attacker who obtains a database of hashes can precompute hashes for every common password and look them up instantly. These precomputed lookup tables are called rainbow tables. An unsalted MD5 hash of "password123" is always the same string — it can be identified almost instantly with a precomputed table.

Salting: the fix for rainbow tables

A salt is a unique random value generated for each user and stored alongside the hash. Before hashing, the salt is appended to the password: salt + password → hash. Now, even if two users choose the same password, their hashes are different because their salts differ. Rainbow tables become useless — the attacker would need to precompute a separate table for every possible salt, which is computationally infeasible.

Modern password hashing algorithms: bcrypt, scrypt, Argon2

MD5 and SHA-1 were designed to be fast — they can compute billions of hashes per second on modern hardware. This speed is the enemy of password security: a fast hash makes brute force attacks cheap. Modern password hashing algorithms are deliberately slow. Bcrypt has a configurable "cost factor" that sets how much work each hash computation requires, typically tuned so that a single hash takes a noticeable fraction of a second. As hardware improves, the cost factor can be increased to maintain the same wall-clock time. Argon2 (the winner of the 2015 Password Hashing Competition) adds memory-hardness: it requires a large amount of RAM per computation, making parallel GPU attacks far more expensive. Scrypt has similar properties. Any of these three is far superior to MD5 or SHA for password storage.

What this means for you as a user

You cannot control how a website stores your password. You can only trust that they follow best practices — which not all do. Some sites still use MD5 or store passwords in plaintext. The breach of a site using bcrypt or Argon2 with proper salting reveals far less, because each guess is slow and must be made per user, although weak passwords can still be guessed; the breach of a site using fast, unsalted hashes such as MD5 lets attackers recover many passwords very quickly. Since you cannot know in advance which category a site falls into, the defence is the same regardless: use a unique password for every site. If Site A is breached and stores passwords poorly, your password there is recovered — but it is useless on Site B because Site B uses a different, equally unique password.

Peppers: an extra layer outside the database

A salt is stored next to the hash and is not secret. Some systems add a pepper as well: a secret value, shared across all passwords, that is kept outside the database, for example in an application secret store or a hardware security module. It is combined with the password or the hash, often through a keyed function such as HMAC. If an attacker steals only the database, they cannot check a single guess without also obtaining the pepper. OWASP describes peppering as a defence-in-depth measure, not a replacement for a slow, salted hash.

What attackers do with a stolen hash database

A leaked database lets attackers guess passwords offline, with no rate limits and no lockouts. They typically start with lists of passwords from earlier breaches, then apply mutation rules such as capitalising a letter or appending digits, and only then fall back on exhaustive search. Because every user has a unique salt, each guess must be hashed separately for each account, so a slow algorithm multiplies the attacker's cost by the number of users they want to attack.

No algorithm can rescue a weak password, though. Common passwords fall first under any scheme, while a long random password stays out of reach even when the site used a fast hash. OWASP currently lists Argon2id as the first choice for new systems, with scrypt, bcrypt (work factor of at least 10) and PBKDF2 (600,000 or more iterations with HMAC-SHA-256) as alternatives where required. That is why your own defence is length, randomness and uniqueness.