WEB / WEB-14.01

Identity, credentials, and password authentication

Identity identifies a subject; a credential supports that claim. Password verification, session establishment, and resource authorization are related but separate decisions.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Authn + action allow

Account claim is prepared
Identifier and credential input are represented only by aliases; there is no raw secret.
Browser / Duru
Account claim; no verified subject
Application
No request
Trusted records
Verifier alias + account/resource policy
Login input reached the Application
The HTTPS request carries the candidate-input alias. Transport protection is supplied; no TLS handshake is simulated.
Browser / Duru
Waiting for decision
Application
Received identifier + candidate alias
Trusted records
Verifier alias + account/resource policy
Local password-verification result
The established verification API result is a supplied boolean here; there is no actual cryptography or record-fetch wire.
Browser / Duru
Waiting for decision
Application
Verified: subject-duru
Trusted records
Verifier unchanged; account allowed
Action/resource policy
The verified subject is allowed for this action/resource relationship.
Browser / Duru
Waiting for decision
Application
ALLOW: read own note
Trusted records
Policy: no client-supplied authority
Decision reached the Browser
credentialMatches and accountAllowed are true in this example, and read own note is allowed for subject-duru. The private representation prepared by the Application has now reached the Browser. This outcome grants no other action.
Browser / Duru
Own note delivered
Application
Response: accepted
Trusted records
Verifier unchanged; policy applied

Credential mismatch

Account claim is prepared
Identifier and credential input are represented only by aliases; there is no raw secret.
Browser / Duru
Account claim; no verified subject
Application
No request
Trusted records
Verifier alias + account/resource policy
Login input reached the Application
The HTTPS request carries the candidate-input alias. Transport protection is supplied; no TLS handshake is simulated.
Browser / Duru
Waiting for decision
Application
Received identifier + candidate alias
Trusted records
Verifier alias + account/resource policy
Local password-verification result
The established verification API result is a supplied boolean here; there is no actual cryptography or record-fetch wire.
Browser / Duru
Waiting for decision
Application
Credential mismatch; no subject
Trusted records
Verifier unchanged; account allowed
Action/resource policy
Credential did not verify; no subject is established.
Browser / Duru
Waiting for decision
Application
DENY: credential failure
Trusted records
Policy: no client-supplied authority
Decision reached the Browser
The credential did not match, so no trusted subject was established and no private representation was prepared. A generic denial reached the Browser. The internal decision is credential failure, distinct from denying an action to an authenticated subject.
Browser / Duru
No private representation
Application
Response: denied
Trusted records
Verifier unchanged; policy applied

Authn success, authz denial

Account claim is prepared
Identifier and credential input are represented only by aliases; there is no raw secret.
Browser / Duru
Account claim; no verified subject
Application
No request
Trusted records
Verifier alias + account/resource policy
Login input reached the Application
The HTTPS request carries the candidate-input alias. Transport protection is supplied; no TLS handshake is simulated.
Browser / Duru
Waiting for decision
Application
Received identifier + candidate alias
Trusted records
Verifier alias + account/resource policy
Local password-verification result
The established verification API result is a supplied boolean here; there is no actual cryptography or record-fetch wire.
Browser / Duru
Waiting for decision
Application
Verified: subject-duru
Trusted records
Verifier unchanged; account allowed
Action/resource policy
The subject is verified; this action lacks permission.
Browser / Duru
Waiting for decision
Application
DENY: action forbidden
Trusted records
Policy: no client-supplied authority
Decision reached the Browser
subject-duru was authenticated, but change Atlas administration settings was not permitted. No private representation was prepared; the denial reached the Browser. Authentication success does not create the missing administration permission.
Browser / Duru
No private representation
Application
Response: denied
Trusted records
Verifier unchanged; policy applied

ACTORS · STATE · DATA FLOW

Identity is a subject within a context

Duru can be a display name, duru.reader a login identifier, and subject-duru the Atlas application’s internal subject reference. These have different jobs. A display name can change or be shared with another user; trusted authorization references should not rely only on that text.

Digital identity represents a subject within a particular service. Proving control of an account using a password does not complete every step needed to associate it with a real person. Identity proofing and everyday authentication answer different questions.

A credential differs from an identifier

A login identifier answers which account is being claimed. A credential concerns a password, security token, or other authenticator used to support that claim. Knowing Duru’s subject ID does not establish knowledge of her password.

A credential need not contain an authorization list. A password alone does not carry permission to edit a book note; it is first verified, then policy is evaluated using the trusted subject context. The next lesson distinguishes transport forms such as API keys and bearer tokens.

Authentication and authorization are different decisions

Authentication evaluates whether a presented authenticator sufficiently supports the relevant identity claim. Authorization determines whether a trusted actor may perform a specific action on a specific resource in the current context.

Duru can authenticate with the correct credential yet lack permission to change Atlas administration settings. Rechecking the password does not create missing permission. Conversely, policy can allow anonymous access to a public book cover; login is not required for every allowed action.

Hiding a UI action is not an authorization decision. A trusted server, gateway, or serverless boundary must enforce access conditions on each request. Resolve identity, tenant, action, and resource relationships from trusted sources rather than a client-provided role string.

Password storage: a verifier instead of plaintext

During registration, the application uses password-hashing/KDF support to produce a verifier instead of retaining readable plaintext. It needs a current, password-specific algorithm with adjustable cost; an ordinary fast SHA-256 digest is not an adequate password-storage choice.

A unique random salt helps prevent the same password from producing identical verifiers across accounts and reduces the value of precomputed comparisons. A salt is not secret and can accompany the verifier record. A pepper, if used, is a separate additional secret protected outside the verifier database; this fixture does not model one.

OWASP Password Storage describes current choices such as Argon2id and alternatives for different platforms. Cost parameters depend on the algorithm and environment capacity; do not prescribe universal figures without workload benchmarking. Use an established library’s salt and encoded-metadata handling rather than inventing a KDF format.

Login: verification without decryption

A login request delivers an identifier and password input to the application under strong transport protection. HTTPS/TLS provides in-transit confidentiality and integrity; it does not automatically fix server password storage. Consider transport protection for both the login form and authenticated pages.

The Application resolves the credential record and uses a library verification API. The library checks the candidate using the recorded salt, algorithm, and cost metadata; it does not decrypt a password hash to recover the password. Account status and any additional required factors or policy conditions can also affect login acceptance.

This fixture teaches single-factor password authentication. credentialMatches is a supplied boolean, not a claim that a real KDF ran. Successful verification establishes a trusted subject-duru context. A new authenticated session is created by the separate session-lifecycle primitive; the raw password input is not written to audit logs.

Credential lifecycle extends beyond the first login

Password changes and recovery alter future control of an account. An active session may not provide enough assurance for sensitive credential changes; apply a current authenticator or appropriate reauthentication condition. Do not assume a password change magically invalidates every existing session and token; a revocation policy is needed.

A verifier cost profile can be upgraded over time. After successful verification, using a library’s rehash-needed result to adopt the current profile is one approach. An old verifier cannot be decrypted into a new profile; safe rehashing uses the candidate available during authentication.

Generic login failures reduce unnecessary clues distinguishing an unknown account from a wrong password. Evaluate response shape, codes, and processing behavior together. Login throttling and MFA are separate defenses; this model measures neither attempt timing nor lockout thresholds or factor coverage.

Read every scenario without motion

Wrong credential

The credential decision was scoped
This branch begins with credentialMatches and accountAllowed fields. The verifier and salt are artifact aliases; this scene performs no actual password or KDF calculation.
Credential check
Predicate not examined
Subject binding
No subject established
Resource policy
Resource withheld
Match and account conditions were separated
The fixture supplies credentialMatches=false and accountAllowed=true. Account policy is distinct from the credential result; both are checked separately when required.
Credential check
credentialMatches=false
Subject binding
No subject established
Resource policy
Resource withheld
The trusted-subject boundary was applied
Credential mismatch leaves subject=null. Knowing login identifier duru.reader or displaying Duru in the UI does not establish an authenticated subject.
Credential check
Match=false
Subject binding
subject=null
Resource policy
Resource withheld
The requested action was evaluated separately
The selected action is read own note. Without an authenticated subject, this private-note action remains authorized=false.
Credential check
Match=false
Subject binding
subject=null
Resource policy
authorized=false
Resource delivery was withheld
resourceDelivered=false is the negative boundary for this branch. Authentication success does not grant every sensitive action; a credential failure does not even establish identity.
Credential check
Match=false
Subject binding
subject=null
Resource policy
resourceDelivered=false
The denial meaning was preserved
This is credential failure; no subject or resource authority is added. Salt and cost-profile aliases add no actual cryptographic verification evidence to this policy outcome.
Credential check
Authn rejected
Subject binding
No trusted subject
Resource policy
Authz deny; no delivery

Forbidden action

The credential decision was scoped
This branch begins with credentialMatches and accountAllowed fields. The verifier and salt are artifact aliases; this scene performs no actual password or KDF calculation.
Credential check
Predicate not examined
Subject binding
No subject established
Resource policy
Resource withheld
Match and account conditions were separated
The fixture supplies credentialMatches=true and accountAllowed=true. Account policy is distinct from the credential result; both are checked separately when required.
Credential check
credentialMatches=true
Subject binding
No subject established
Resource policy
Resource withheld
The trusted-subject boundary was applied
Successful credential matching establishes subject-duru. Display name Duru and trusted subject are different fields; UI text does not establish identity.
Credential check
Match=true
Subject binding
subject-duru
Resource policy
Resource withheld
The requested action was evaluated separately
The selected action is change Atlas administration settings. Even with an authenticated subject, Atlas administration settings have authorized=false.
Credential check
Match=true
Subject binding
subject-duru
Resource policy
authorized=false
Resource delivery was withheld
resourceDelivered=false is the negative boundary for this branch. Authentication success does not grant every sensitive action; a credential failure does not even establish identity.
Credential check
Match=true
Subject binding
subject-duru
Resource policy
resourceDelivered=false
The denial meaning was preserved
This is authn success/authz denial; labelling it merely a failed login hides which boundary made the decision.
Credential check
Authn accepted
Subject binding
Trusted subject present
Resource policy
Authz deny; no delivery

ASSUMPTION · BOUNDARY · CONTROL

Observe subjects, credentials, and permissions separately

In a defensive review, displaying Duru in the UI is not proof of an authenticated subject. Login acceptance, resolved subject, and resource decisions need separate evidence fields. Observe that credential failure establishes no subject, while authn success/authz denial establishes a subject but withholds the resource.

The credential-mismatch branch shows how a supplied false predicate affects the decision. A successful predicate does not automatically allow every sensitive action.

Interpret the verifier’s boundary correctly

Salts and slow hashing reduce risks from verifier-database disclosure; they do not solve every issue involving weak passwords, credential reuse, or authenticated-session disclosure. Keeping a salt secret is not the foundation of password security.

A frontend secret or Browser-readable verifier copy can spread server-side credential material across a broader trust boundary. Review records, backups, recovery paths, and logs for unnecessary credential material.

Read every scenario without motion

Complete decision

The observation scope was selected
This branch examines credential, subject, action and delivery fields together from the normal row. Missing fields are not filled with success assumptions.
Decision observation
normal decision: full row
Boundary correlation
Boundaries not correlated
Integrity conclusion
Delivery unknown
Credential and account results were read
credentialMatches=true and accountAllowed=true are supplied. Observation carries no raw password, verifier or salt bytes; an unnecessary credential copy is not required.
Decision observation
normal decision: full row
Boundary correlation
Match and account allowed
Integrity conclusion
Delivery unknown
The resolved subject was correlated
subject=subject-duru records the identity outcome. DisplayName Duru and loginIdentifier duru.reader have separate roles; matching text is not promoted to permission evidence.
Decision observation
normal decision: full row
Boundary correlation
Resolved subject: subject-duru
Integrity conclusion
Delivery unknown
Action evidence was sought separately
The full row shows action=read own note and authorized=true. This grant belongs only to that action; it is not expanded to administration permission.
Decision observation
normal decision: full row
Boundary correlation
Authz: own note allowed
Integrity conclusion
Delivery unknown
The delivery field was compared
resourceDelivered=true is present in the full row. Review checks consistency with both earlier gates, without adding an HTTP status or actual browser appearance.
Decision observation
normal decision: full row
Boundary correlation
Authn+authz known
Integrity conclusion
Delivery=true
The integrity conclusion was scoped
The main selector searches for delivered=true with either gate false and returns 0. This complete row is consistent; it measures no actual password performance or timing security.
Decision observation
normal decision: full row
Boundary correlation
Decision consistent
Integrity conclusion
Matrix integrity consistent

Action gap

The observation scope was selected
This branch examines only credential and subject fields from the normal row. Missing fields are not filled with success assumptions.
Decision observation
normal decision: authn-prefix review
Boundary correlation
Boundaries not correlated
Integrity conclusion
Delivery unknown
Credential and account results were read
credentialMatches=true and accountAllowed=true are supplied. Observation carries no raw password, verifier or salt bytes; an unnecessary credential copy is not required.
Decision observation
normal decision: authn-prefix review
Boundary correlation
Match and account allowed
Integrity conclusion
Delivery unknown
The resolved subject was correlated
subject=subject-duru records the identity outcome. DisplayName Duru and loginIdentifier duru.reader have separate roles; matching text is not promoted to permission evidence.
Decision observation
normal decision: authn-prefix review
Boundary correlation
Resolved subject: subject-duru
Integrity conclusion
Delivery unknown
Action evidence was sought separately
This prefix does not examine action authorization. An authenticated subject does not complete an object or sensitive-action outcome.
Decision observation
normal decision: authn-prefix review
Boundary correlation
Authz evidence missing
Integrity conclusion
Delivery unknown
The delivery field was compared
Delivery lies outside this scope. Neither delivered nor withheld can be concluded definitively; separate delivery evidence is required.
Decision observation
normal decision: authn-prefix review
Boundary correlation
Only authn known
Integrity conclusion
UNKNOWN: delivery
The integrity conclusion was scoped
An authn prefix cannot evaluate the entire integrity predicate. Missing action and delivery evidence is not evidence of a leak; it remains an evidence gap.
Decision observation
normal decision: authn-prefix review
Boundary correlation
Action evidence required
Integrity conclusion
UNKNOWN: resource outcome

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Apply resource policy after resolving a verified subject

The authentication component should return an explicit subject and assurance context. Downstream policy evaluates action/resource/tenant relationships through trusted data; username or display-name equality is not permission.

Define the reason for anonymous access to public resources separately from required subjects and permissions for private resources. The two product flows need not impose the same password requirement.

Keep password handling within a library boundary

Use an established password-hash verification API, unique salts, recorded algorithm/cost metadata, and a rehash flow when needed. Choose production parameters using current guidance and workload measurements; do not copy this lesson’s cost-profile alias as configuration.

Input handling, generic failure, throttling, MFA, and secure recovery are defenses outside the password hash. Verify framework/library behavior and failure boundaries instead of writing custom timing or KDF primitives.

Keep decisions in audit, not credentials

A credential-match result, resolved-subject alias, account-policy result, and action decision can suffice for observation. Raw passwords, verifiers, and session secrets are unnecessary. A hash-profile upgrade can also be recorded as a nonsecret policy event.

The synthetic matrix has three outcomes: authn+authz success, credential failure, and authn success/authz denial. Collapsing them into one “login failed” entry hides the decision boundary; public responses and internal audit should remain separate.

NOW APPLY IT TO THE CASE

Which actions are not automatically allowed by credential verification?

Duru’s name, credential outcome, trusted subject and resource policy are distinct fields. Negative decisions and missing observations remain separate.

Separate decisions for verified actor, tenant relation and requested action in the case. Do not substitute authentication or proof success for object permission.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Identity and authentication decision matrix

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "identity": {
    "displayName": "Duru",
    "loginIdentifier": "duru.reader",
    "trustedSubject": "subject-duru",
    "tenant": "Atlas"
  },
  "credentialRecord": {
    "verifier": "VERIFIER_ALIAS_ONLY_NOT_A_HASH",
    "salt": "UNIQUE_SALT_ALIAS_NOT_RANDOM_BYTES",
    "algorithmClass": "password-specific adaptive KDF",
    "costProfile": "LIBRARY_PROFILE_ALIAS_NOT_PARAMETERS",
    "plaintextStored": false
  },
  "cases": [
    {
      "case": "normal",
      "credentialMatches": true,
      "accountAllowed": true,
      "subject": "subject-duru",
      "action": "read own note",
      "authorized": true,
      "resourceDelivered": true
    },
    {
      "case": "wrong-credential",
      "credentialMatches": false,
      "accountAllowed": true,
      "subject": null,
      "action": "read own note",
      "authorized": false,
      "resourceDelivered": false
    },
    {
      "case": "authenticated-forbidden",
      "credentialMatches": true,
      "accountAllowed": true,
      "subject": "subject-duru",
      "action": "change Atlas administration settings",
      "authorized": false,
      "resourceDelivered": false
    }
  ],
  "selector": {
    "xml": "<authentication><decision case=\"normal\" authenticated=\"true\" authorized=\"true\" delivered=\"true\"/><decision case=\"wrong-credential\" authenticated=\"false\" authorized=\"false\" delivered=\"false\"/><decision case=\"authenticated-forbidden\" authenticated=\"true\" authorized=\"false\" delivered=\"false\"/></authentication>",
    "xpath": "count(/authentication/decision[@delivered=\"true\" and (@authenticated!=\"true\" or @authorized!=\"true\")])",
    "expected": 0,
    "positiveFixtureXml": "<authentication><decision authenticated=\"true\" authorized=\"false\" delivered=\"true\"/></authentication>",
    "positiveExpected": 1
  }
}

loginIdentifier / trustedSubject: The claimed account differs from the trusted subject established after successful verification.
credentialRecord: An alias record showing salt/verifier/cost roles, not a real hashing format.
credentialMatches / authorized: Separates the authentication predicate from the resource-policy outcome.
resourceDelivered: A private representation is delivered only after required authn and authz conditions pass.

Single-factor conceptual fixture. credentialMatches and accountAllowed are supplied inputs; no password, KDF, MFA, timing, or real login endpoint was executed. The alias record is not production configuration.

Two reality checks

A correct password proves a real-world identity and grants access to every resource.

Authentication supports an account claim; identity proofing and action/resource authorization are separate processes.

A password hash is decrypted at login and is secure because the salt stays secret.

A verification API checks the candidate using salt/algorithm/cost metadata without decryption. Salts are not secret; suitable password KDFs and credential lifecycle controls are required.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

Credential matches is true, but the action changes Atlas admin settings. Is establishing a subject enough for resource delivery?

Yes; password verification permits every action.
No; authorized=false in the authenticated-forbidden case.

Read the explained answer

No; authorized=false in the authenticated-forbidden case. — A trusted subject may be established without granting this subject the selected administrative action.

Do the verifier/salt aliases establish that actual password-hash security was measured?

Selected lesson artifact fields; teaching example

credentialRecord: {"verifier":"VERIFIER_ALIAS_ONLY_NOT_A_HASH","salt":"UNIQUE_SALT_ALIAS_NOT_RANDOM_BYTES","algorithmClass":"password-specific adaptive KDF","costProfile":"LIBRARY_PROFILE_ALIAS_NOT_PARAMETERS","plaintextStored":false}

No; this artifact contains no real hash/random bytes/parameters.
Yes; seeing a salt alias validates random generation and cost calibration.

Read the explained answer

No; this artifact contains no real hash/random bytes/parameters. — The adaptive password-specific KDF role is described; costProfile is LIBRARY_PROFILE_ALIAS_NOT_PARAMETERS.

What different roles do loginIdentifier duru.reader, displayName Duru and trustedSubject subject-duru play?

Read the explained answer

DisplayName is a UI label; loginIdentifier may select an account for credential lookup. TrustedSubject is the principal established after successful verification/policy. Shared display names do not merge identities; storing plaintext passwords is not the verifier-lifecycle model.

□ I distinguished display/lookup/principal roles.

□ I did not describe a verifier as recoverable plaintext.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

OWASP — Authentication Cheat SheetIntroduction · User IDs · Compare Password Hashes Using Safe Functions · Transmit Passwords Only Over TLS or Other Strong Transport · Authentication and Error Messages · Require Re-authentication for Sensitive Features · Login Throttling
OWASP — Password Storage Cheat SheetHashing vs Encryption · Salting · Peppering · Using Work Factors · Upgrading the Work Factor · Password Hashing Algorithms: Argon2id
OWASP — Authorization Cheat SheetIntroduction · Validate the Permissions on Every Request · Verify that Authorization Checks are Performed in the Right Location
OWASP — Session Management Cheat SheetRenew the Session ID After Any Privilege Level Change · Logging Sessions Life Cycle

YOUR NOTES / THIS BROWSER

Identity, credentials, and password authentication

1. Core · Mechanism

Authn + action allow

Credential mismatch

Authn success, authz denial

Identity is a subject within a context

A credential differs from an identifier

Authentication and authorization are different decisions

Password storage: a verifier instead of plaintext

Login: verification without decryption

Credential lifecycle extends beyond the first login

2. Red · Trust & Impact

Wrong credential

Forbidden action

Observe subjects, credentials, and permissions separately

Interpret the verifier’s boundary correctly

3. Blue · Secure development & defense

Complete decision

Action gap

Apply resource policy after resolving a verified subject

Keep password handling within a library boundary

Keep decisions in audit, not credentials

Which actions are not automatically allowed by credential verification?

Two reality checks

Credential matches is true, but the action changes Atlas admin settings. Is establishing a subject enough for resource delivery?

Do the verifier/salt aliases establish that actual password-hash security was measured?

What different roles do loginIdentifier duru.reader, displayName Duru and trustedSubject subject-duru play?

Sources and scope