Authentication Study Portal

A: Because SHA-256 is fast, which helps the attacker. A GPU can compute billions of SHA-256 hashes per second, so a stolen database can be brute-forced or dictionary-attacked at enormous speed. bcrypt/scrypt/Argon2id are deliberately slow and tunable (and Argon2id/scrypt are memory-hard), making each guess expensive and large-scale cracking impractical.

A: A salt is a unique, random value added to each password before hashing and stored with the hash. It stops precomputed rainbow-table attacks and ensures two users with the same password produce different hashes, so an attacker must crack each hash individually.

A: A salt is per-password and stored in the database next to the hash; a pepper is a single secret kept outside the database (app config / HSM / KMS) and mixed into every hash. If only the DB leaks, the pepper still protects the hashes. The pepper supplements salts — it never replaces them.

A: Credential stuffing replays username/password pairs leaked from other breaches, exploiting password reuse. Brute force tries many guessed passwords against one account. Stuffing is high-yield because the credentials are already valid somewhere; defenses include breached-password checks, MFA, rate limiting, and anomaly detection.

A: In session fixation an attacker plants or learns a session ID before the victim logs in, then reuses that now-authenticated session. Prevent it by regenerating (rotating) the session ID on every login and privilege change, and by never accepting a session ID from the URL.

A: Secure ensures the cookie is only sent over HTTPS (stops network sniffing). HttpOnly blocks JavaScript access (mitigates session theft via XSS). SameSite=Strict/Lax limits cross-site sending (mitigates CSRF).

A: alg: none means the token is unsigned. If the server honors it, an attacker can strip the signature and forge arbitrary claims (e.g. admin: true) to impersonate anyone. The fix is to pin the expected algorithm server-side and reject none.

A: localStorage is readable by any JavaScript on the page, so a single XSS flaw can exfiltrate the token. Safer: store it in an HttpOnly; Secure; SameSite cookie (unreadable by JS), or keep a short-lived token only in memory.

A: A JWT is self-contained and trusted until its exp, so there's no server lookup to invalidate. Teams use short-lived access tokens paired with a revocable, server-stored refresh token, or maintain a deny-list of token IDs (jti) to reject specific tokens early.

A: Distinguishing "user not found" from "wrong password" — via message, status code, or timing — lets an attacker enumerate valid accounts, which fuels targeted brute force and credential stuffing. A uniform response (and uniform timing) closes the enumeration channel.

A: WebAuthn uses origin-bound public-key cryptography: the authenticator signs a challenge with a private key tied to the real site, and the key never leaves the device. Because the credential is bound to the origin, a phishing site can't relay it — it's phishing-resistant. TOTP and SMS codes can be phished or (for SMS) intercepted via SIM swap.

A: The Implicit flow returned tokens directly in the URL fragment, exposing them to leakage, and is deprecated. Authorization Code + PKCE returns a short-lived code and binds it to the client that started the flow (via the code verifier/challenge), defeating code interception — and PKCE is now recommended for all client types.

A: It should be high-entropy, single-use, and short-lived; only its hash is stored server-side; it's delivered out-of-band; the response never reveals whether the account exists; and on successful reset all other active sessions are invalidated.

A: OAuth 2.0 is an authorization framework for delegated access to resources. OIDC adds an authentication layer on top, issuing an id_token that proves who the user is. For "log in with X", you want OIDC, not bare OAuth.

A: Forced rotation pushes users toward predictable, incremental passwords (Password1 → Password2) and frequent reuse, weakening security overall. NIST SP 800-63B recommends rotating only on evidence of compromise, while screening new passwords against breached/common lists and favoring length.