How does a basic password-based login protocol work, and what does the server actually store?

Setup: client sends password once, server stores its hash. Login: client sends password, server hashes and compares with the stored hash.

The two phases:

Setup phase (one-time):

• Alice sends her password to Bob's server over a secure channel.
• Bob computes Hash(password) and stores only the hash — never the plaintext password.

Login phase (every session):

• Alice sends "I'm Alice, <password>".
• Bob computes Hash(password) on the received value.
• Bob compares with the stored hash — if equal, login succeeds (ok); otherwise it fails (not ok).

Why hash, not the password itself:

• If Bob's database is leaked, the attacker has hashes, not passwords. They still need to brute-force each one.
• Modern practice: use a slow salted hash function (bcrypt, scrypt, Argon2) — the slowness makes brute-forcing each password expensive.

Weak spot: the password still travels to the server in plaintext during login. This is why TLS is non-negotiable: it protects the channel. Challenge-response protocols (next cards) eliminate even this exposure.