Which hashlib functions are built for password storage, and why not hashlib.sha256?

`hashlib` exposes two families of function, and only one of them belongs anywhere near a password. ## The digest family `hashlib.sha256`, `hashlib.sha512` and `hashlib.blake2b` are **general-purpose cryptographic digests**. They take bytes and return a fixed-length digest as fast as the machine can manage — speed is their design goal, because they exist to fingerprint files, messages and cache keys. On a current CPU with hardware SHA instructions a single core computes SHA-256 at hundreds of megabytes per second, and purpose-built hardware does far better. If a users table storing `sha256(salt + password)` leaks, the attacker owns an **offline oracle** they can drive at that rate against a wordlist, one row at a time. The salt is still doing its job: - it stops one precomputed table from covering every row; - and it stops two accounts with the same password showing the same stored value. But a salt does not make a single guess any slower. Salting is not the missing ingredient. **Cost is.** ## The password family `hashlib.pbkdf2_hmac(hash_name, password, salt, iterations, dklen=None)` and `hashlib.scrypt(password, *, salt, n, r, p, maxmem=0, dklen=64)` are **password-based key-derivation functions**. Their defining feature is that the caller chooses how expensive one evaluation is. - **PBKDF2** repeats an HMAC over the password `iterations` times. - **scrypt** additionally forces the evaluation through a large working area of memory, which is what makes it awkward to parallelise on hardware built for cheap hashing. The **asymmetry** is the whole point: the defender evaluates the function once per login, the attacker once per guess, so a cost that is a barely noticeable delay for you is a wall for them. ## Arguments and types - Both functions take `bytes`, not `str`. Passing a `str` password raises `TypeError: a bytes-like object is required, not 'str'`, which is the right failure — encode explicitly with `password.encode("utf-8")` so the encoding is a decision rather than an accident, and so the same password verifies identically on every machine. - The **salt** is bytes too: generate 16 fresh bytes per user with `os.urandom(16)` (or `secrets.token_bytes(16)`) when the password is set, and store them in clear beside the derived key. A salt is not a secret; it is a uniqueness device, and it must be stored or you can never verify again. - `dklen` picks the output length — PBKDF2 defaults to the digest size of `hash_name`, scrypt defaults to 64 bytes. ## Anti-patterns that look like the fix - Writing a Python loop that calls `hashlib.sha256` a hundred thousand times is slow for you and still cheap for an attacker running optimised native code, and it is a home-made construction nobody has analysed. - Using the username as the salt makes the salt predictable and shared across systems. - Storing the derived key without recording which algorithm and parameters produced it makes every later change impossible. - And re-hashing the stored digest with a stronger function does not upgrade the record; it just builds a bespoke chain you must then carry forever. ## What the standard library does not give you On 3.14 there is no Argon2 and no bcrypt in `hashlib`, no encoded record format, and no built-in "does this stored value need re-hashing" check. You write the string that carries algorithm, parameters, salt and derived key, and you write the upgrade path. Both KDFs are thin wrappers over the interpreter's linked **OpenSSL** — CPython dropped the slow pure-Python PBKDF2 fallback in 3.12 — so an interpreter built without suitable OpenSSL support does not expose them at all. ## Verification To check a password you re-derive with the stored salt and the stored parameters and compare the two byte strings with a **constant-time comparison**, never with `==` on the hex text. And the comparison direction matters: you never decrypt a stored password, because a KDF output is not reversible; you only recompute and compare. ## Choosing the cost Neither function has a safe default, because the right value depends on your hardware and your tolerance for login latency. 1. Measure: time one derivation on a machine like production. 2. Raise `iterations` or `n` until a single call costs the largest delay you are willing to add to every login. 3. Then write the chosen value into the stored record rather than into a constant, so it can move later. A number copied from a tutorial written years ago is the most common way a correct call ends up providing a fraction of the protection it appears to. ## What to say in an interview - Name the two functions. - Say that the salt defeats precomputation while the **work factor** defeats speed. - And point out the trap in the question: `hashlib.sha256` sits in the same module behind the same import, so the wrong primitive is always one attribute away from the right one.