Identifiers vs Credentials vs Secrets

Three categories that look similar in storage but require completely different handling. Mixing them up is one of the easiest ways to leak something you didn't realize was sensitive.

Category	Examples	Sensitivity	Handling
Identifier	Username, email, user_id, IP address	Low (often public)	Plain text fine; index for lookup
Credential	Password, PIN, biometric, hardware key	High (proves identity)	Never store plain; always hash with bcrypt/argon2/scrypt
Secret	API key, JWT signing key, session token, OAuth client secret	High (grants access without further proof)	Encrypted at rest; never in repo; rotate-able

The hashing bright line

If a value is something the user knows (password, PIN), you should never be able to recover the original from your storage. The only way to verify it is to hash the input and compare hashes:

Why bcrypt and not SHA256? Because SHA256 is too fast: a GPU can try billions per second. Bcrypt is intentionally slow (~100ms per hash at default cost), making brute force economically painful even on stolen hashes.

The three failure patterns

Identifier treated as secret — Hiding usernames or IDs as if they're sensitive. Wastes effort; they leak via logs anyway.
Credential stored as identifier — Plain-text passwords in DB. The classic catastrophic breach.
Secret committed to repo — API key in .env that got pushed once and lives forever in git history. Track 9 covers how LLM-assisted coding makes this worse.

Code

Hash a PIN with bcrypt (storage); verify by re-hashing input·python

import bcrypt

# Storage — never plain text
pin = b"4729"
pin_hash = bcrypt.hashpw(pin, bcrypt.gensalt(rounds=12))
# Save pin_hash in DB; the original PIN never persists

# Verification — compare hashes, never decrypt
def verify(input_pin: str, stored_hash: bytes) -> bool:
    return bcrypt.checkpw(input_pin.encode(), stored_hash)

Identifiers vs Credentials vs Secrets

The hashing bright line

The three failure patterns

Code

External links

Exercise

Progress

Comments 0