Chapter 13 — Identity and access

Chapter 13 — Identity and access

Lesson map

Lesson 13 published. Map, example, EX037.

flowchart TD
  N0["Learning outcomes"]
  N1["13.1 Authentication factors"]
  N2["13.2 Comparing methods"]
  N3["13.3 Access design"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX037"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["13.1 Authentication factors"]
  N2["13.2 Comparing methods"]
  N3["13.3 Access design"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX037"]

[Learning outcomes]
    |
    v
[13.1 Authentication factors]
    |
    v
[13.2 Comparing methods]
    |
    v
[13.3 Access design]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX037]

Learning outcomes

You will (1) explain how cryptography supports authentication; (2) compare passwords, one-time codes and security keys; (3) design access for staff and patrons.

13.1 Authentication factors

Authentication proves identity using something you know, have or are. Passwords are knowledge; phones generating one-time codes and hardware security keys are possession. Priya studies how one-time codes work: the phone and server share a secret and compute short codes from it and the current time using HMAC, so a stolen password alone is not enough. Hardware security keys go further, using public-key signatures bound to the website's name, which stops phishing sites from replaying responses. Priya demonstrates both factors in a staff workshop.

13.2 Comparing methods

Priya compares methods for Tidewell staff. Passwords alone are vulnerable to phishing and reuse. Time-based codes stop many attacks but can be phished in real time by a fake site that relays codes. Security keys resist phishing because the key signs a challenge that includes the real site's origin, and a fake site's origin produces a useless signature. She recommends security keys for administrators and staff with access to patron data, and one-time codes as a fallback, noting costs and the need for spare keys.

13.3 Access design

For patrons, Priya recommends passwords or passphrases with optional one-time codes, since requiring hardware keys would exclude many users. For staff she designs role-based access: branch staff see their branch's patrons; administrators use separate accounts with security keys; and service accounts use certificates rather than shared passwords. She documents that authentication proves who someone is but authorisation decides what they may do, and that both must be reviewed when staff change roles or leave. Access reviews are scheduled every six months with branch managers.

Worked example

Priya recommends security keys for administrators and data-handling staff, optional one-time codes for patrons, and role-based access with certificate-based service accounts.

Synthetic case. Tidewell's roles are invented.

Errors and limits

Strong authentication cannot fix excessive permissions. Recovery processes are often the weakest link.

Exercises

• EX037 — One-time codes. How are time-based one-time codes computed? Rubric: 3 = HMAC over a shared secret and the current time;; 2 = HMAC;; 1 = random;; 0 = none.
• EX038 — Phishing resistance. Why do security keys resist phishing? Rubric: 3 = they sign a challenge bound to the real site's origin, useless for fake sites;; 2 = origin binding;; 1 = they don't;; 0 = none.
• EX039 — Patron accessibility. Why not require hardware keys for patrons? Rubric: 3 = it would exclude many users;; 2 = exclusion;; 1 = cost only;; 0 = none.

Synthesis

Cryptography strengthens authentication, from HMAC-based codes to origin-bound security keys, but access design must balance security and inclusion.

Continue studying — chapter 13 of 40

← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →