Authentication Deep Dive

#Password Security

Last verified2026-06

#The one idea: a password hash must be SLOW on purpose

You never store the password itself — you store a hash, a one-way fingerprint of it. To log you in, the server hashes what you typed and checks it equals the stored hash. If the database leaks, the attacker gets only fingerprints and has to guess: pick a candidate password, hash it, see if it matches.

So the entire game is one number: how many guesses per second can the attacker make? Everything about password hashing exists to drive that number down.

A normal hash like SHA-256 is built to be fast — perfect for checking file integrity, a disaster for passwords. On a modern GPU an attacker computes billions of SHA-256 hashes per second, so a leaked database of SHA-256 password hashes is cracked almost for free. The fix is a hash that is deliberately expensive to compute, tuned so one login costs the server a few milliseconds but costs the attacker that same few milliseconds on every one of their billions of guesses.

#Hashing Algorithms — Why It Matters

Argon2id configuration

from argon2 import PasswordHasher

ph = PasswordHasher(
    time_cost=2,       # iterations
    memory_cost=65536, # 64 MB RAM required per hash
    parallelism=2,     # threads
)

hash = ph.hash("user_password")
ph.verify(hash, "user_password")  # raises exception on mismatch

#Why Argon2id is so hard to break

You can make a single guess expensive in two ways: cost the attacker CPU time, or cost them memory. Argon2id does both, and the memory part is what really breaks the attacker's economics.

The problem with "slow but small" (bcrypt). bcrypt is CPU-hard — each guess takes real time — but it uses only about 4 KB of memory. Attackers don't crack on normal CPUs; they use GPUs (thousands of small cores) and custom chips (FPGAs, ASICs) that pack in even more cores. When each guess needs only 4 KB, you can run tens of thousands of guesses in parallel on one card, because tiny memory is cheap to replicate next to each core. bcrypt is still acceptable, but it doesn't fight this parallelism.

What "memory-hard" means (Argon2id)Argon2id forces each guess to allocate a big block of RAM — say 64 MB — and to read and write all over it in a sequence you can't shortcut. Now the attacker's hardware advantage collapses:

• A GPU has thousands of cores but limited memory and memory bandwidth. If each guess needs 64 MB, a 16 GB card can run only ~250 guesses at once instead of tens of thousands. The cores sit idle waiting on memory.
• ASICs lose their edge too. Their trick is stamping out millions of cheap compute units, but RAM takes physical silicon area that costs the attacker the same as it costs anyone. Memory is the great equaliser: a megabyte costs the attacker what it costs the defender, unlike raw compute.

Why you can't cheat by using less memory. The obvious dodge is "store less, recompute the missing values on the fly" — trade memory back for compute. Argon2 is designed so that dropping below the target memory makes the required compute blow up far faster than the memory you saved, so it's never worth it. It also uses data-dependent addressing in its later passes: which memory cell it touches next depends on the data it just computed, so the attacker can't predict and pre-fetch the access pattern or pipeline it on a GPU.

Why the "id" in Argon2idArgon2 has three variants:

The three knobsmemory_cost (RAM per guess — the main weapon), time_cost (number of passes over that memory), and parallelism (independent lanes). You turn these up as hardware improves; the defender pays the cost once per login, the attacker pays it on every guess. Argon2id won the Password Hashing Competition in 2015.

Memory hook

make the attacker rent RAM, not just burn CPU. A fast hash (SHA-256) is a sprint the GPU wins easily. bcrypt makes it a long run — better, but the GPU just fields thousands of runners. Argon2id makes every runner drag a 64 MB suitcase: now you can only fit a few hundred on the track at once, and no custom chip makes RAM cheaper than it is for the defender. CPU-hard slows one guess; memory-hard caps how many guesses run in parallel — and parallelism is the attacker's whole advantage.

#Salting

A salt is a unique random value generated per password and stored alongside the hash. Purpose: prevents precomputed rainbow tables from working, and ensures identical passwords hash differently.

hash = Argon2id(password + salt)
stored = salt + "$" + hash

Modern password hashing libraries (bcrypt, Argon2) handle salting automatically — never implement this manually.

#Credential Stuffing vs Brute Force

#OAuth 2.0 — Flows and Security

OAuth 2.0 is a delegation protocol — it lets a user grant a third-party application access to their resources on another service, without sharing their password.

Memory hook

OAuth is a valet keyA valet key starts the car and opens the door but won't open the trunk or glovebox — it's scoped, delegated access you hand a stranger without giving them your master key (password). That's OAuth: the app gets a token that can do some things on your behalf, and you can revoke it without changing your password. The crucial interview line: OAuth is for authorization (what you can access), NOT authentication (who you are) — using a raw OAuth access token to "log someone in" is the classic mistake that OIDC was created to fix.

#Roles

#The flow in plain English

Before the raw HTTP below, here's what actually happens when you click "Log in with Google" on some app:

Why the two-step dance (a code first, then the token)? So the powerful access token never travels through the browser or a URL, where it could be logged by a proxy, sit in history, or leak through a referrer header. Only the throwaway code rides through the browser — and that code can only be redeemed by the app that started the flow, which is exactly what PKCE enforces.

#Authorisation Code Flow + PKCE (The Correct Flow)

User → Client: "Login with Google"
Client → Auth Server: GET /authorize?
    response_type=code
    &client_id=...
    &redirect_uri=https://app.com/callback
    &scope=openid profile email
    &state=<random>           ← CSRF protection
    &code_challenge=<sha256(verifier)>  ← PKCE
    &code_challenge_method=S256

Auth Server → User: Login page
User → Auth Server: Authenticate + Consent
Auth Server → Client: GET /callback?code=<auth_code>&state=<random>

Client: verify state matches

Client → Auth Server: POST /token
    grant_type=authorization_code
    &code=<auth_code>
    &redirect_uri=https://app.com/callback
    &code_verifier=<original_verifier>  ← PKCE verification
    &client_id=...
    [&client_secret=... if confidential client]

Auth Server → Client: {
    access_token: "...",
    token_type: "Bearer",
    expires_in: 3600,
    refresh_token: "...",
    id_token: "..."    ← OIDC only
}

PKCE (Proof Key for Code Exchange)

• Client generates a random code_verifier (43–128 chars)
• Sends SHA256(code_verifier) as code_challenge in the auth request
• Sends the raw code_verifier at token exchange
• Prevents authorisation code interception — stolen code is useless without the verifier
• Mandatory for public clients (SPAs, mobile apps); strongly recommended for all

Memory hook

PKCE is a coat-check ticketYou keep a secret stub (code_verifier) and hand over only its hash (code_challenge) when you start. At the end you present the original stub to prove you're the same party who began the flow. A thief who intercepts the authorization code can't redeem it — they never had the stub. This matters most for mobile/SPA apps that can't keep a client secret, because the app binary is on the attacker's device. Mnemonic: PKCE = "Pixie" dust that binds the start of the flow to its finish.

State parameterrandom nonce tied to the user's session; verified on callback. Prevents CSRF on the OAuth flow (attacker starts their own auth flow and tricks victim into completing it with their session).

#Common OAuth Vulnerabilities

#OpenID Connect (OIDC)

#What is this?

OAuth gives an app permission to do things on your behalf, but it deliberately says nothing about who you are. OpenID Connect (OIDC) is a thin layer on top of OAuth 2.0 that adds exactly that missing piece: a standard, verifiable answer to "who just logged in?"

It reuses the entire OAuth Authorization Code + PKCE flow — same redirects, same endpoints — and changes two things: you add the openid scope to the request, and you get back one extra item alongside the access token: an ID Token.

#Access token vs ID token — the distinction that matters

This is the single most-tested OIDC idea:

The classic bug OIDC was invented to fix: developers used a raw OAuth access token to "log the user in." But an access token is just a bearer key — an attacker who obtains a token issued for another app can present it to yours and impersonate the user. The ID token closes this because it carries an aud (audience) claim naming your client, and a nonce tying it to your specific login request.

// Decoded ID Token payload
{
  "iss": "https://accounts.google.com",  // who issued it
  "sub": "1234567890",                   // stable unique user ID
  "aud": "your-client-id",               // who it was issued FOR (must be you)
  "exp": 1700000000,                     // expiry
  "iat": 1699996400,                     // issued-at
  "email": "user@example.com",
  "email_verified": true,
  "nonce": "random-nonce"                // ties token to YOUR auth request
}

Validations required when receiving an ID Token (each line is a real attack you're blocking):

1. Verify the signature using the issuer's public key — otherwise the token is forgeable.
2. Check iss matches the expected issuer — otherwise a different IdP's token is accepted.
3. Check aud matches your client_id — this is what stops a token minted for another app being replayed at yours.
4. Check exp is in the future — otherwise expired tokens are replayed.
5. Check nonce matches what you sent in the auth request — ties the token to this login, blocks replay of an old one.
6. Check iat is not implausibly old — defends against stale-token replay.

#Where the keys come from

The issuer publishes a discovery document at https://issuer/.well-known/openid-configuration, which points to a jwks_uri (JSON Web Key Set) holding its public signing keys. Your app picks the key matching the kid in the token header and verifies the signature. Nothing secret is shared — verification uses only public keys.

Memory hook

OAuth authorizes, OIDC authenticatesWhen someone "logs in with Google," the part that proves who they are is OIDC's ID token (signed, audience-bound, nonce-bound), not the OAuth access token (a bearer capability that proves nothing about identity). Mix them up and you get the single most common federation bug: treating a stealable access token as proof of login.

#SAML 2.0 — Enterprise SSO

#What is this?

SAML does the same job as OIDC — let you log into one app using your identity from a central provider — but it predates the OAuth/OIDC web-API era. Instead of JSON tokens it uses signed XML documents, and it's everywhere in corporate single sign-on (Okta, Azure AD / Entra, PingFederate, Google Workspace).

Two parties:

The trust is cryptographic and one-way: the IdP writes a signed statement — "this is alice@corp.com, role admin" — called an assertion, and signs it with its private key. The SP holds the IdP's public certificate and checks the signature. If valid, the SP trusts the contents and logs you in. No password ever reaches the SP.

Quick contrast: SAML is XML carried by a browser form POST, dominant in workforce/B2B SSO; OIDC is JSON/JWT over REST, dominant in consumer, mobile, and single-page apps. Same goal (federated SSO), different era and shape.

#Flow (SP-initiated)

User → Service Provider (SP): access protected resource
SP → User: redirect to IdP with SAMLRequest (base64 XML)
User → IdP: authenticate
IdP → User → SP: HTTP POST /acs with SAMLResponse (signed XML assertion)
SP: verify signature → grant access

#SAML Assertion Structure

<saml:Assertion>
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <ds:Signature>...</ds:Signature>    ← covers what exactly?
  <saml:Subject>
    <saml:NameID>user@example.com</saml:NameID>
  </saml:Subject>
  <saml:AttributeStatement>
    <saml:Attribute Name="role">
      <saml:AttributeValue>admin</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

#SAML Attacks

XML Signature Wrapping (XSW)The signature covers a specific element by ID. The attack moves the signed element and inserts a malicious one, tricking parsers that evaluate the assertion differently from the signature verifier.

<!-- Original signed assertion (ID="legit") -->
<Assertion ID="legit"><Signature>...</Signature><NameID>user</NameID></Assertion>

<!-- XSW: wrap it, add malicious assertion -->
<Assertion ID="evil"><NameID>admin</NameID>
  <Assertion ID="legit"><Signature>...</Signature><NameID>user</NameID></Assertion>
</Assertion>
<!-- Signature validates "legit", but SP uses "evil" (first found) -->

MitigationsUse a hardened SAML library; validate signature covers the assertion element you're using; check InResponseTo; enforce replay protection via AssertionID cache.

#JWT — Structure, Attacks, Mitigations

#What is this?

A JWT (JSON Web Token, said "jot") is a small, self-contained token that carries claims — facts like "user = 1234, role = admin, expires at 17:00" — in a format anyone can read but only the issuer can produce. Its whole value is being stateless: the server can verify a JWT with just a key, no database lookup, because the token carries its own proof of authenticity in the signature.

That self-contained nature is also its danger. Everything rests on verifying the signature correctly, so every attack below is ultimately a way to make the server skip or weaken that check. And note: a JWT is signed, not encrypted — the payload is only base64-encoded, readable by anyone who holds the token, so never put secrets in it.

#Structure

header.payload.signature

Header: base64url({ "alg": "RS256", "typ": "JWT" })
Payload: base64url({ "sub": "1234", "role": "user", "exp": 1700000000 })
Signature: RS256(base64url(header) + "." + base64url(payload), private_key)

#Attack 1: alg: none

Attacker sets "alg": "none" and removes the signature. Vulnerable libraries that accept any algorithm will trust the unsigned token.

# Malicious token
import base64, json

header = base64.urlsafe_b64encode(json.dumps({"alg":"none","typ":"JWT"}).encode()).rstrip(b'=')
payload = base64.urlsafe_b64encode(json.dumps({"sub":"admin","role":"admin"}).encode()).rstrip(b'=')
token = header + b'.' + payload + b'.'  # empty signature

MitigationPin the algorithm server-side — never accept what the token header says. jwt.decode(token, key, algorithms=["RS256"]), not algorithms=["RS256", "none"].

Memory hook

never let the envelope tell you how to check the seal. Both big JWT attacks (alg:none and RS256→HS256 confusion) share one root cause: the server trusts the alg field in the attacker-controlled header to decide how to verify. alg:none says "don't check the seal at all"; algorithm confusion says "check this asymmetric signature as if it were a symmetric one, using the public key as the password." The single defense for both: hard-code the expected algorithm server-side and ignore the header's claim. Remember: the header is the attacker's; the verification rules are yours.

#Attack 2: Algorithm Confusion (RS256 → HS256)

If the server accepts both RS256 (asymmetric) and HS256 (symmetric):

1. Get the server's RSA public key (often at /.well-known/jwks.json or /oauth/public-keys)
2. Create a new token with "alg": "HS256" and sign it with the public key as the HMAC secret
3. The server's HS256 code uses the public key to verify — it passes

MitigationNever allow the algorithm to be specified in the token. Dedicate a key per algorithm; don't share keys between RS256 and HS256 contexts.

#Attack 3: Weak Secret (HS256 Brute Force)

HS256 tokens signed with weak secrets can be cracked offline:

hashcat -a 0 -m 16500 token.txt wordlist.txt
# or
python3 jwt_tool.py <token> -C -d wordlist.txt

MitigationUse 256-bit random secrets for HS256; prefer RS256/ES256 (asymmetric) for distributed systems where multiple services verify tokens.

#Attack 4: JWT Claim Tampering Without Signature Check

If the application doesn't verify the signature — or uses the wrong key — any payload can be injected.

#Secure JWT Usage

import jwt
from datetime import datetime, timedelta

SECRET = os.environ["JWT_SECRET"]  # 32+ random bytes

def create_token(user_id: str, role: str) -> str:
    return jwt.encode({
        "sub": user_id,
        "role": role,
        "iat": datetime.utcnow(),
        "exp": datetime.utcnow() + timedelta(hours=1),
        "jti": secrets.token_hex(16),   # unique ID — enables revocation
    }, SECRET, algorithm="HS256")

def verify_token(token: str) -> dict:
    # Pinning algorithm — never accept what the token claims
    return jwt.decode(token, SECRET, algorithms=["HS256"], options={"require": ["exp", "sub"]})

#WebAuthn / FIDO2 / Passkeys

#Why It's Better Than Everything Else

#How It Works

Registration

1. Server generates a challenge (random bytes)
2. Browser calls navigator.credentials.create() with the challenge
3. Authenticator (YubiKey / platform authenticator) creates a new key pair; private key never leaves the device
4. Authenticator signs the challenge + client data + origin using the private key
5. Public key + credential ID sent to server → stored in the database

Authentication

1. Server generates a new challenge
2. Browser calls navigator.credentials.get() with the challenge
3. Authenticator signs the challenge using the private key for the matching credential
4. Server verifies the signature using the stored public key
5. Origin is cryptographically bound — a phished login on bank-secure.evil.com won't produce a valid signature for bank.com

#Passkeys

Passkeys are WebAuthn credentials synced across devices (iCloud Keychain, Google Password Manager). The private key is exported in encrypted form and synced to other devices. Provides phishing resistance with the convenience of passwords.

#Kerberos — AD Authentication

#Protocol Flow

1. AS-REQ: Client sends username + timestamp encrypted with password hash
   → KDC (Key Distribution Centre, DC)

2. AS-REP: KDC returns:
   - TGT (Ticket Granting Ticket): encrypted with krbtgt hash
   - Session key: encrypted with client's key

3. TGS-REQ: Client presents TGT to get service ticket
   - Sends: TGT + authenticator (encrypted with session key)

4. TGS-REP: KDC returns TGS (service ticket) encrypted with target service's key

5. AP-REQ: Client presents TGS to target service → authenticated

Memory hook

Kerberos is a theme parkAt the gate you show ID once and get a wristband (TGT) from the ticket office (KDC) — now you don't show ID again all day. To ride a specific attraction you swap the wristband for a ride ticket (TGS) for that ride, and the ride operator (the service) just checks the ticket. The names map cleanly: AS-REQ/REP = get the wristband, TGS-REQ/REP = get a ride ticket, AP-REQ = hand the ticket to the ride. Why it matters for attacks: a Golden Ticket forges the wristband (krbtgt key = the whole park's master), a Silver Ticket forges one ride ticket (one service's key, never touches the KDC so it's stealthier). Mnemonic: Gold = the master gate, Silver = a single door.

Memory hook

why Kerberoasting works at allAny authenticated user can request a service ticket for any service, and that ticket is encrypted with the service account's password hash. So the attacker asks for the ticket legitimately, then cracks it offline at their leisure — no failed logins, no lockouts, nothing noisy on the wire. That's why service accounts with weak, human-set passwords (and high privileges) are the prize. The fix is long random passwords (or gMSAs, which use 120-char machine-managed passwords that are uncrackable).

#Attack Techniques

KerberoastingAny domain user can request a TGS for any SPN (Service Principal Name). The TGS is encrypted with the service account's NTLM hash — take it offline and crack.

# Enumerate SPNs and request tickets
python3 GetUserSPNs.py domain/user:password -dc-ip 10.10.10.10 -request

# Crack with hashcat
hashcat -m 13100 kerberoast_hash.txt /usr/share/wordlists/rockyou.txt

AS-REP RoastingAccounts with "Do not require Kerberos preauthentication" set can be attacked without credentials.

python3 GetNPUsers.py domain/ -usersfile userlist.txt -dc-ip 10.10.10.10
hashcat -m 18200 asrep_hash.txt wordlist.txt

Golden TicketForge a TGT using the krbtgt NTLM hash (obtained via DCSync or DC compromise). Valid for 10 years by default. Gives persistent domain admin access even after password resets (except krbtgt reset).

# With mimikatz (post-DC-compromise)
lsadump::dcsync /user:krbtgt
kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /krbtgt:<hash> /id:500

Silver TicketForge a TGS using the target service account's NTLM hash. Doesn't touch the KDC → harder to detect. Scoped to one service.

Pass-the-TicketSteal a TGT/TGS from LSASS memory and inject into current session.

# With mimikatz
sekurlsa::tickets /export
kerberos::ptt ticket.kirbi

#MFA Methods Compared

MFA fatigue attackbombard the user with push notifications until they approve one by mistake. Mitigated by: number matching (user must enter the code shown in the push app), geographic/time anomaly detection, rate limiting push requests.

#Session Management

#Secure Session Architecture

User authenticates →
  Server generates: session_id = secrets.token_urlsafe(32)  # 256 bits
  Stores: session_store[session_id] = {user_id, created_at, last_active, ip, ua}
  Sets cookie: Set-Cookie: session=<session_id>; HttpOnly; Secure; SameSite=Strict; Path=/

Subsequent requests →
  Server looks up session_id in session_store
  Validates: not expired, not revoked, optional IP/UA binding
  Returns appropriate response

#Session Cookie Attributes

Set-Cookie: session=abc123;
  HttpOnly;              # JS cannot read — blocks XSS-based theft
  Secure;                # HTTPS only
  SameSite=Strict;       # CSRF protection
  Path=/;                # scope to root
  Max-Age=3600;          # 1 hour expiry
  Domain=app.example.com # don't set Domain if you want to exclude subdomains

#Session Attacks