Storing passwords and API keys

What it is

Human-chosen passwords have low entropy, so their stored form must make guessing expensive: OWASP recommends Argon2id, with scrypt and bcrypt as alternatives, each with a per-password salt and a tuned work factor. Randomly generated API keys with at least 256 bits of entropy cannot be guessed, so a fast keyed hash (an HMAC with a server secret) is sufficient to verify them without storing the key itself.

Why it matters

A database leak should not reveal credentials. Slow hashing limits offline guessing of passwords; HMAC storage of API keys means the database alone cannot be used to authenticate.

How to apply

• Passwords: hash with Argon2id (or bcrypt/scrypt), store algorithm parameters with the hash, re-hash on login when parameters change, and follow NIST 800-63B on length limits and breached-password checks rather than composition rules.
• API keys: generate with a cryptographic random source, show the full key exactly once, store only a keyed hash plus a non-secret prefix for identification, and compare hashes in constant time.
• Rate-limit authentication attempts and support rotation and revocation.

Pitfalls

Fast hashes (SHA-256 alone) for passwords. Truncating input before hashing. Returning the stored key in profile responses. Logging the Authorization header.