This trace describes one server-side password login. Frameworks and protocols differ, and multi-factor authentication or passkeys add further steps.
1. Bound the attempt
The server validates request shape, applies rate limits and abuse controls, and normalizes the account identifier according to its policy. Responses should avoid revealing whether a particular account exists when that distinction would help enumeration.
2. Load the verifier
The service retrieves the account's password verifier and algorithm parameters from protected storage. It should never load or compare a plaintext password because a plaintext password should not be stored.
3. Verify the secret
The password-hashing library combines the submitted password with the stored salt and parameters, then compares the derived result using the library's safe verification operation. Slow, memory-hard or deliberately expensive password hashing raises the cost of offline guessing after a database leak. Parameters should be selected and upgraded with operational capacity in mind.
4. Establish an authenticated session
After successful verification, the server creates or rotates a session identifier and records the authenticated principal and relevant expiry. The browser receives the session in a cookie configured for the application's threat model, commonly including Secure, HttpOnly, and an appropriate SameSite value. Authorization is still checked on each protected operation.
Use a maintained framework and password library. OWASP's Password Storage Cheat Sheet describes current storage guidance.