Question 4 of 7: Two-Factor Authentication, Single-Sign-On, and Password Storage

Question 4: Two-Factor Authentication, Single-Sign-On, and Password Storage (20 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part a) — two-factor authentication. Two-factor authentication (2FA) requires a user to present valid credentials from two different categories of authentication factor before access is granted — typically something you know (a password/PIN), something you have (a hardware token, smart card, or a code generated on a registered phone), or something you are (a biometric) — not two credentials of the same type. Example: logging into online banking with a password (something you know) plus a six-digit one-time code sent to, or generated on, the user's registered phone (something you have) — an attacker who has phished the password still cannot log in without also possessing the phone.

Part b) — single sign-on. A single-sign-on (SSO) system lets a user authenticate once, to one trusted identity provider, and then access multiple independent applications/services without re-entering credentials at each one — the identity provider issues a signed token or ticket (e.g. a SAML assertion, an OAuth/OIDC token, or a Kerberos ticket) that each downstream service trusts and validates. Security advantages: (1) users need to remember and protect only one strong credential, reducing the temptation to reuse weak passwords across systems; (2) authentication policy (password strength, MFA, lockout) is centralised at the identity provider and enforced consistently, rather than implemented separately by each application; (3) revoking a user's access can be done in one place and immediately takes effect across every connected service, which matters for fast offboarding.

Part c) — storing password hashes, and the purpose of a salt. Systems store $H(\text{password})$ instead of the password itself for several reasons: (1) if the credential store is stolen (database breach, backup theft, malicious insider), the attacker obtains only hashes, which must still be cracked (guessed, then re-hashed and compared) rather than being immediately usable plaintext; (2) it limits exposure to insiders and administrators who have database access but have no legitimate need to see users' actual passwords, satisfying a least-privilege/defense-in-depth principle; and (3) verification never needs the plaintext after registration — the system only re-hashes a login attempt and compares it to the stored hash, so no code path or log ever has to carry the real password in the clear. A salt is a random value, unique per user, generated at password-set time, stored alongside (not secretly) the resulting hash, and mixed into the input before hashing: $\text{stored} = H(\text{salt} \,\|\, \text{password})$. Its purpose is to defeat precomputed attacks: without a salt, an attacker can build one rainbow table/lookup of common-password hashes and instantly crack every account using a password in that table, and any two users with the same password get the identical stored hash (revealing the duplicate and letting one cracked hash unlock every account sharing it); with a per-user salt, the attacker must attack each salted hash individually, since a precomputed table for one salt does not help against any other salt.