19-Soft-B3 Security · May 2014
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, May 2014 — 04-Soft-B3, Security/Safety (closed book, 3 hours, no calculator). FIVE of the seven questions constitute a complete paper (the first five as answered in the answer book are marked, each of equal value); this solution answers all seven as a full study resource. Most questions call for essay-format answers; clarity and organisation of the answer are important. Question 6 asks for a security analysis of a short C program.
Reference texts. Stallings & Brown, Computer Security: Principles and Practice, 4th ed., Ch. 2–3 (Cryptographic Tools, One-Time Pad, Block Ciphers), Ch. 21 (Public-Key Infrastructure, Certificate Authorities), Ch. 3 (Hash Functions, MAC), Ch. 23 (Digital Signatures), Ch. 3 & 24 (User Authentication, Two-Factor, SSO), Ch. 9 (Firewalls, DMZ), Ch. 8 (Intrusion Detection, Honeypots), Ch. 10 (Buffer Overflow); Anderson, Security Engineering, 3rd ed., Ch. 4 (Access Control, Least Privilege), Ch. 1 & 9 (Defense in Depth, Separation of Duty).
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) — three fundamentally different authentication factors. (1) Something you know — a password, PIN or passphrase, verified by comparison against a stored (hashed) value. (2) Something you have — a physical or virtual possession, such as a hardware security token, smart card, or a one-time-code generator/authenticator app on a phone, verified by proving possession of it (e.g. producing the current code it generates). (3) Something you are — a biometric characteristic (fingerprint, iris/retina pattern, facial geometry, voiceprint), verified by matching a captured sample against an enrolled template. These are fundamentally different because they rely on different security assumptions and fail differently: a password can be guessed or phished without the user noticing, a token can be physically stolen, and a biometric cannot be "reset" once compromised.
Part b) — two-factor authentication. Two-factor authentication (2FA) requires a user to present valid credentials from two different categories of Part a) before access is granted — not two credentials of the same type (two passwords give no meaningful extra assurance, since compromising the same channel/weakness that exposed one likely exposes the other). 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 c) — 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 instead of many, 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 everywhere, rather than being implemented (and potentially implemented weakly) by each application separately; (3) revoking a user's access — e.g. on termination — can be done in one place and immediately takes effect across every connected service, instead of having to be actioned system by system.
