Password vs Public-Key Authentication

This comparison is directly assessed in the 2025 Tripos Paper 2 Q5(b), a 14-mark part. You must discuss both how login works and how cross-server post authentication works — the question asks for both.

How Password Authentication Works

1. The user registers with a username and password.
2. The server hashes the password with a salt (a random per-user value) using a slow, computationally-expensive hash function (bcrypt, scrypt, Argon2) and stores the salt and the hash. The plaintext password is never stored.
3. To log in, the user submits their credentials over TLS (encrypted transport). The server hashes the provided password with the stored salt and compares the result to the stored hash.
4. On match, the server issues a session token (typically an opaque random string or a signed JWT) that the client includes in subsequent requests.

How Public-Key Authentication Could Work

Login to the Home Server (Challenge-Response)

1. The user generates a key pair locally. The public key is registered with their home server. The private key never leaves the user’s device.
2. To log in, the server sends a random challenge (a nonce — a large random number used once).
3. The client signs the challenge with the private key. The signature proves possession of the private key without revealing it.
4. The server verifies the signature against the stored public key. On success, it issues a session token.
5. Crucially, no secret (password or private key) ever crosses the network. A network observer, or even a compromised server, cannot learn the private key.

Cross-Server Post Authentication

1. When a user creates a post, the post payload is digitally signed by the author’s private key.
2. When the post is federated to another server, that server fetches the author’s public key from the author’s home server (analogous to fetching a TLS certificate).
3. The receiving server verifies the signature against the public key. This cryptographically proves: “this post was authored by the holder of the private key corresponding to this public key, and it has not been tampered with in transit.”
4. Under password authentication, cross-server authenticity has no equivalent mechanism. Server B must simply trust Server A’s word that a post is genuine — a Spoofing vulnerability (STRIDE).

Comparison Table

Aspect	Password	Public-Key
Secret transmitted over the network?	Yes (over TLS) — vulnerable if server or TLS is compromised; vulnerable to phishing (user types password into a fake login page)	No — only a signed challenge is sent. Resistant to phishing and server-side credential database breaches.
Server-side breach impact	Stolen hash database can be subjected to offline brute-force and dictionary attacks (especially if the hash function is weak or unsalted)	Only public keys are stored on the server. A breach discloses no secret — an attacker learns who the users are but cannot impersonate them.
Usability	Familiar to all users. Easy recovery: “forgot password” → email reset link.	Unfamiliar to most users. Key management is hard: no simple “forgot key” recovery path. Losing the private key with no backup can mean permanent loss of account control.
Cross-server trust (federated / decentralised setting)	Each server independently manages passwords; a compromised server cannot forge other servers’ users anyway (password hash comparison only works locally), but there is no way for Server B to verify that a post attributed to Server A’s user is genuine — it must trust Server A’s claim.	A signature is independently, cryptographically verifiable by any receiving server. Directly mitigates Spoofing and Repudiation for federated content.
Revocation	Change password instantly via email reset.	Revoking a compromised key requires a distribution mechanism (e.g. a Certificate Revocation List) so that all servers know the old key is invalid.
Key / credential loss	Password reset via secondary channel (email) is straightforward and widely understood.	Losing the private key — if the user did not back it up — can mean permanent loss of account control. No recovery mechanism equivalent to “forgot password.”

A Balanced Recommendation (Hybrid)

A strong exam answer proposes a hybrid approach:

• Login: keep passwords (with two-factor authentication) for login usability. Login is a human-facing, low-frequency operation where usability and recoverability dominate.
• Post authentication: adopt public-key signing for every federated post. Post authentication is a machine-to-machine, high-frequency operation where cryptographic verifiability is essential, and the human usability concern (“I lost my signing key”) does not apply moment-to-moment — it only matters at key-creation and key-revocation time.

This hybrid isolates the usability burden of key management to infrequent operations (key generation, device enrolment, key rotation) while gaining the cryptographic verifiability that a decentralised trust model demands.

Expected Learning

• Describe the challenge-response mechanism for public-key login, explaining why the private key never crosses the network.
• Describe how signed posts enable cross-server authentication in a decentralised system.
• Compare password and public-key authentication across: secret transmission, server-breach impact, usability, cross-server trust, revocation, and key-loss recovery.
• Propose and justify a hybrid approach tailored to the specific needs of login (usability) and federation (cryptographic verifiability).

---

Past Paper Questions

The 2025 Tripos Paper 2 Q5(b) is the definitive source — a 14-mark part. The model answer is reproduced in full in the Examinable Material section.