09 — Password Hashing and Federation — Storing Secrets, Delegating Identity

MD5, SHA, scrypt, bcrypt, OAuth, SAML — these looked like unrelated trivia scattered through the caching section of the roadmap. Writing them down split them into two clean ideas: password hashing is a one-way race the server must deliberately lose slowly, and OAuth/SAML are two dialects of one idea — delegate identity to a party both sides already trust. [1]

The two halves sound unrelated but they answer the same question from opposite directions: how do I prove who I am without handing over the secret? Hashing answers it for passwords you store yourself — never store the password, store a fingerprint you can verify but can't reverse. Federation answers it by refusing to handle the secret at all — let someone else verify the user and hand you a token. Both keep the actual secret out of your database.

Hashing: one-way, deterministic, and the slow kind

A hash function takes any input and produces a fixed-size digest — MD5 produces 128 bits, SHA-256 produces 256 bits — such that the same input always yields the same digest, but the digest cannot be reversed back to the input [3][4]. Two properties define a cryptographic hash:

• One-way (preimage-resistant). Given a digest, you cannot compute the input.
• Collision-resistant. You cannot find two different inputs that hash to the same digest.

For password storage, the use is direct: instead of storing password123, store hash(password123). On login, hash what the user typed and compare digests. If the database leaks, the attacker has hashes, not passwords.

Here's the part I had to internalize: not all hash functions are suitable for passwords. General-purpose hashes (MD5, SHA-256) are designed to be fast — that's their job for integrity checking. But for passwords, fast is the enemy. An attacker with a leaked hash will try billions of candidate passwords per second; a fast hash means billions of guesses per second per GPU.

MD5 is broken — collision vulnerabilities mean it's unsuitable for anything security-critical, and it's far too fast for passwords [2]. Never use MD5 for passwords.

SHA-2 / SHA-3 are still cryptographically sound for integrity and signatures, but they're also too fast for password storage. SHA is not a password hash.

For passwords, you want password hashes — functions deliberately designed to be slow and memory-hard:

• bcrypt — based on the Blowfish cipher, with a tunable cost factor and built-in salt [5]. The cost factor doubles the work each time you raise it, so you can keep pace with hardware. bcrypt is the battle-tested default for password storage.
• scrypt — a memory-hard KDF (key-derivation function) designed to resist GPUs and ASICs by requiring large amounts of memory per hash, making hardware attacks expensive [6]. Where bcrypt raises CPU cost, scrypt raises memory cost.

The way of thinking: a password hash must be slow on purpose. A login taking 250ms is fine for a human and devastating for an attacker brute-forcing billions of guesses. The server must lose the race to compute the hash, slowly, on purpose.

Salt: defeating rainbow tables

A salt is random bytes added to the password before hashing, stored alongside the hash. Its job is to ensure that two users with the same password get different hashes — defeating rainbow tables (precomputed tables of hash→password mappings).

Without salt, password123 hashes to the same digest for every user, so an attacker who leaks the DB instantly finds every user sharing the most common password. With a unique salt per user, each hash is unique even for identical passwords, and the attacker has to brute-force each one independently. bcrypt and scrypt build the salt in; with raw SHA you'd have to handle it yourself (another reason not to use raw SHA).

OAuth 2.0: delegation of authorization

OAuth 2.0 is the authorization protocol that lets a user grant a third-party application limited access to their resources on another service, without handing the application their password [7]. The classic flow: "Allow this app to read your GitHub repos." The user authenticates with GitHub (the authorization server), GitHub issues the app an access token, and the app uses that token to call GitHub's API on the user's behalf.

The key idea is delegated authorization via tokens. The app never sees the user's GitHub password; it sees a token that says "GitHub authorized this app to do these specific things." Tokens can be scoped (read-only, one repo) and revoked (the user can kill the app's access without changing their password).

OAuth 2.0 is authorization, not authentication — it answers "what can this app do?", not "who is the user?" That's a common confusion. Authentication on top of OAuth (confirming who the user is) is what OpenID Connect adds.

SAML: enterprise federation in XML

SAML (Security Assertion Markup Language) is the older, XML-based federation standard common in enterprise [8]. Where OAuth/OIDC is the modern web's federation story (JSON, JWTs, REST), SAML dominates enterprise single sign-on — the "log in with your corporate identity" flow at universities and large companies.

A SAML flow: the user tries to access a service provider (SP); the SP redirects to an identity provider (IdP); the user authenticates at the IdP; the IdP posts a signed XML assertion back to the SP asserting who the user is. The SP trusts the assertion because it trusts the IdP's signing certificate.

SAML and OAuth/OIDC solve overlapping problems — both let you delegate identity/authorization to a trusted third party — but in different ecosystems. SAML is XML, enterprise, browser-redirect-based, and predates the modern web. OAuth/OIDC is JSON, API-first, and what new federations use. The roadmap lists both because both exist in production; which one I meet depends on whether the integration partner is an enterprise (SAML) or a modern service (OAuth).

The two halves, together

What unifies the hashing half and the federation half is the principle: the secret never lives where it can be leaked. Password hashing keeps the plaintext out of the database (the DB can leak and passwords survive). Federation keeps the plaintext out of your system entirely (you never see it; the IdP does). Both are defenses against the same risk — the database breach — approached from two different starting points.

The decision shape:

• You store users and passwords → hash them with bcrypt (or scrypt/argon2). Never MD5, never raw SHA, always salted.
• You want "sign in with X" → OAuth 2.0 / OpenID Connect. The modern web default.
• Enterprise partner mandates SSO → SAML. Common in corporate/education integrations.

How I use this

Two habits capture the practice. For password storage, I never roll my own hashing — I use the platform's bcrypt/argon2 implementation and I set the cost factor so a single hash takes ~250ms on production hardware, re-tuning every couple of years as hardware speeds up. For identity, I default to OAuth via a provider (Supabase, Auth0, the platform's built-in) rather than building custom password flows, because federation removes the password database as an attack surface entirely. The portfolio uses Google OAuth through Supabase for exactly this reason — the passwords I don't store are passwords I can't leak.

The framing — hashing loses slowly, federation delegates — is what keeps me from reaching for the wrong tool. MD5 is fast and broken; SHA is fast and for integrity; bcrypt is slow and for passwords. OAuth is for the modern web; SAML is for the enterprise. Picking by purpose, not by familiarity, is the whole skill.

References

[1] roadmap.sh, "Backend Roadmap — Security nodes." [Online]. Available: https://roadmap.sh/backend

[2] "MD5," Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/MD5

[3] "What is SHA?," Encryption Consulting. [Online]. Available: https://www.encryptionconsulting.com/education-center/what-is-sha/

[4] "Why is MD5 not safe?," InfoSec Scout. [Online]. Available: https://infosecscout.com/why-md5-is-not-safe/

[5] "Understanding bcrypt," Auth0. [Online]. Available: https://auth0.com/blog/hashing-in-action-understanding-bcrypt/

[6] "scrypt," Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/Scrypt

[7] "An Introduction to OAuth 2," DigitalOcean. [Online]. Available: https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

[8] "SAML Explained in Plain English," OneLogin. [Online]. Available: https://www.onelogin.com/learn/saml