Authentication

Matching password

1. Claim. The browser names Chronos Hub account FL-17 and holds a password to submit. The name selects an account; it does not establish the claim. There is no authenticated session yet. This fictional password-only example uses Chronos Hub account FL-17, linked to Kael Cho. The account already has a stored salt, password-hashing settings, and a reference password hash. Password characters and hash values are deliberately not displayed. Other policies may require additional authenticators; this is not an MFA flow or a complete login implementation.
2. Submit. The browser sends the account name and password over a protected channel. Chronos Hub receives them before verification starts. The stored account and its reference hash remain at the service. The moving label represents a credential submission over an authenticated protected channel, such as HTTPS. The recipient displays Received only after arrival. The browser does not send the stored reference hash or download the account record. Transport establishment and account lookup details are omitted.
3. Verify. Chronos Hub applies the stored password-hashing scheme, salt, and cost settings to the submitted password, then compares the result with the stored reference. A match is evidence for this account’s claim. In this authored successful outcome the entire submitted password produces the expected result under the stored settings. This depicts the verifier’s comparison, not a browser-side hash equality shortcut or a real computation performed by the illustration. A password match supports control of the bound authenticator; a shared, stolen, or phished password does not establish which human supplied it. Passwords are not phishing-resistant.
4. Respond. Chronos Hub creates a session for FL-17 after verification and returns its sign-in result. The browser shows the authenticated session only after that response arrives. Reading a trailer’s records still requires authorization. The service creates and associates its session with the authenticated account, then the browser receives the response. The diagram summarizes session establishment; it omits cookies, session secrets, rotation, expiry, and other implementation details. No trailer records are returned here. A later resource request must be checked against the account’s permissions, and this session is not proof that Kael Cho is physically at the device.

Wrong password

1. Claim. The browser names Chronos Hub account FL-17 and holds a password to submit. The name selects an account; it does not establish the claim. There is no authenticated session yet. This fictional password-only example uses Chronos Hub account FL-17, linked to Kael Cho. The account already has a stored salt, password-hashing settings, and a reference password hash. Password characters and hash values are deliberately not displayed. Other policies may require additional authenticators; this is not an MFA flow or a complete login implementation.
2. Submit. The browser sends the account name and password over a protected channel. Chronos Hub receives them before verification starts. The stored account and its reference hash remain at the service. The moving label represents a credential submission over an authenticated protected channel, such as HTTPS. The recipient displays Received only after arrival. The browser does not send the stored reference hash or download the account record. Transport establishment and account lookup details are omitted.
3. Verify. Chronos Hub applies the stored password-hashing settings to the submitted password. In this outcome the result differs from the reference, so password verification fails. No authenticated session is created. The stated account exists in this example, but the submitted password is incorrect. Only password verification fails; account lookup and receipt still hold. This is not a conclusion about the requester’s real-world identity. A production service also needs rate limiting and carefully designed failure responses; those controls are outside this illustration.
4. Respond. Chronos Hub returns a sign-in refusal after the mismatch. The browser displays it only after arrival and receives no authenticated session. This failed attempt does not establish who submitted the password. The failed sign-in creates no authenticated session for FL-17. The response communicates refusal, not an authorization decision about trailer data. Receipt remains successful and the reference record remains unchanged. The authored choice differs only in the submitted password; it is not a simulation of account enumeration, lockout policy, or an actual backend login.

Authentication verifies account-bound evidence for this event. It does not prove which human is at the device or authorize a particular task. The figure uses authored outcomes, not a real sign-in service.

Flow references: NIST SP 800-63B-4 - Password Verifiers · NIST SP 800-63B-4 - Authentication Assurance · OWASP - Authentication and Authorization