Password Verification and Login Budgets

Password verification compares a submitted secret with a stored password verifier, not with reversible plaintext. Use a vetted password-hashing facility with a unique salt and a deliberately costly algorithm; keep the algorithm parameters with the stored record so they can be raised later. A successful check establishes identity for this request, after which the server creates or rotates a separate session. The login endpoint must also bound repeated attempts and return similar public feedback for an unknown account and a wrong password. A per-address limit alone can punish a shared office or be bypassed across addresses, so combine account, source, and abuse signals without revealing which account exists. The snippet is one decision boundary; a deployed service should use its platform's maintained password library rather than implementing a hash format by hand.

Working case

Reviewer 29 signs in before editing case 47. The server looks up the account, verifies the submitted password through the configured slow verifier, checks the attempt budget, then issues a fresh session reference. The browser receives a cookie carrying that reference, never the stored verifier. If the account is absent, the response uses the same public wording as a wrong secret. When a password record uses older cost parameters, a successful login can rehash it with current parameters inside a controlled update. None of these steps authorizes access to case 47; record-level permission remains a later request decision.

Implementation boundary

function classifyLoginAttempt({ accountFound, passwordMatches, attemptsRemaining }) {
  if (!attemptsRemaining) return { status: 429, publicMessage: "Try again later" };
  if (!accountFound || !passwordMatches) {
    return { status: 401, publicMessage: "Sign-in details were not accepted" };
  }
  return { status: 200, nextStep: "rotate session identifier" };
}

Cost and boundaries

A password verifier intentionally consumes CPU and often memory for each attempt. That cost slows guessing but can also amplify a denial-of-service attempt if the endpoint has no budget. Account lookup and attempt tracking add storage or shared-counter work; a multi-worker service needs a shared rule. Parameter upgrades may make a successful login slower once, so measure the distribution rather than silently raising costs beyond service capacity. Never log raw passwords, derived hashes, or complete authentication headers; retain only safe outcomes and correlation IDs.

Failure trace

A developer stores a fast digest of the password and treats a 401 as enough abuse control. A stolen database can then be tested rapidly offline, while a distributed online attacker continues to guess. Another implementation says 'no account found' for one input and 'wrong password' for another, letting the endpoint enumerate users. Replace the storage method with a maintained slow verifier, keep public responses uniform, and make the budget decision before expensive work where possible without creating a timing leak.

Verification

Register two accounts with the same password and confirm their stored verifiers differ because their salts differ.
Send wrong and nonexistent-account attempts; compare public status and wording without exposing account existence.
Exhaust the login budget across two app workers and confirm the shared rule still blocks the next attempt.

Decision note

Authentication proves who is making a request; authorization decides which case that person may read. Keep these operations separate in code, tests, and logs so a successful login cannot become blanket permission.

Common Mistakes

Do not store passwords or a fast unsalted digest as the verifier.
Do not place a password hash or session secret in client-side storage.
Do not treat a successful login as permission for every record.

Connected lessons

Identity and Application Security; Account Recovery and Session Revocation; Federated Login Callback Boundary; Outbound URL Requests and SSRF Boundaries; Sessions and CSRF: keep identity on the server; Authorization: check permission for this record on every request; Rate Limits and Request Budgets; Environment Configuration and Secret Boundaries.

Apply and check

Build Project: account access and recovery boundary and review Web Development: identity and integration contracts quiz.