Passwords and PINs

A familiar secret

Alex opens the staff portal for Cedar Inc. and enters a password. The service checks it against the password set for Alex's account. A match shows that the person signing in knows the password. It cannot show whether anyone else knows it too.

Alex can use that password on a different device without bringing anything along. But the password can also be copied, reused on another site, or typed into a page that only looks like the staff portal.

Checking a password

When Alex sets a password, the service creates a random value called a salt for that password record. It gives both the password and the salt to a password-hashing function designed to be slow. The service stores the resulting hash, the salt, and the settings needed to check the password later. It does not keep a readable copy of the password.

If Alex and another employee choose the same password, each record gets a different salt, so their stored hashes differ. The salt can be stored alongside the hash because its job is to make each record's calculation different, not to serve as another secret. The slow hashing function makes each guess more expensive if someone steals the records.

At sign-in, the password library checks what Alex entered against the stored record. It does not decrypt the hash to recover the original password.

In simplified pseudocode, the check looks like this:

record = load_account_password_record(account_id)
accepted = password_library.verify(record, supplied_password)
if accepted and account_is_allowed_to_sign_in:
    establish_session()
else:
    reject_sign_in()

Where passwords fail

Someone can try passwords repeatedly at the staff portal's sign-in page. The service can limit those online attempts. If its password database is stolen, guesses can instead be tested against the copied hashes without visiting the sign-in page. Slow, salted hashing raises the cost of those guesses, but a weak password may still be found.

Reuse creates another path into Alex's account. If Alex chose the same password for work and a shopping site, a breach at the shopping site could expose a working password for the staff portal. Trying exposed account names and passwords at other services is called credential stuffing.

Phishing does not require guessing or a stolen password database. Someone makes a page that looks like the staff portal's sign-in page and persuades Alex to enter the password there. The person running that page receives the password, even if Alex chose a strong one.

A unique work password prevents a shopping-site breach from revealing the same secret. A password manager helps Alex keep those passwords distinct. Cedar Inc. can reject known compromised passwords when Alex sets or changes one. If Alex's work password is disclosed, it needs to be changed.

A PIN on your device

Now Alex signs in with a security key. Alex inserts it and enters a PIN when prompted. The security key checks the PIN locally before using its cryptographic key to produce a signed response. Cedar Inc. verifies that response; it never receives the PIN.

The security key can limit repeated PIN guesses because it controls the check. A short code that a website receives and checks itself works differently, even if the form also calls it a PIN.