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 Password policies"]
  N3["13.3 Usable authentication"]
  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 Password policies"]
  N3["13.3 Usable authentication"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX037"]

[Learning outcomes]
    |
    v
[13.1 Authentication factors]
    |
    v
[13.2 Password policies]
    |
    v
[13.3 Usable authentication]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX037]

Learning outcomes

You will (1) explain authentication factors; (2) evaluate password policies with human factors evidence; (3) recommend usable authentication.

13.1 Authentication factors

Authentication checks that someone is who they claim to be, using something they know, such as a password; something they have, such as a card or security key; or something they are, such as a fingerprint. Combining factors makes stolen passwords less useful. Nadia notes that Ashcombe uses passwords alone for the library management system, which holds member addresses. A phishing email that captures a password would give full access, so adding a second factor would reduce the damage a single deceived person could cause.

13.2 Password policies

Ashcombe requires staff to change passwords every sixty days with complex rules. Adams and Sasse (1999) found that such rules lead people to write passwords down or use predictable patterns, because memorising many changing passwords is hard. Nadia surveys a small group of colleagues anonymously and finds that most add a number to their old password at each change. She recommends ending forced periodic changes unless there is evidence of compromise, and allowing longer passphrases, which are easier to remember and harder to guess.

13.3 Usable authentication

Nadia compares options for a second factor: text message codes, an authenticator app on personal phones and security keys. Counter staff do not all have work phones, and some prefer not to use personal phones for work. Security keys work without phones and resist phishing because they check the website. She recommends keys for staff who access member data, with a simple backup process. Her recommendation balances security, cost and the practical situation of staff, which she learned to weigh in earlier chapters.

Worked example

Nadia explains factors, links forced changes to weak passwords, and recommends passphrases and security keys.

Synthetic case. The survey is synthetic; Adams and Sasse (1999) is real.

Errors and limits

Keys can be lost. Ending forced changes needs compromise detection.

Exercises

• EX037 — Three factor types. What are the three factor types?
  Show marking criteria

  Rubric: 3 = know, have, are;; 2 = three;; 1 = vague;; 0 = none.
• EX038 — Forced change effect. What did Nadia find staff do at forced changes?
  Show marking criteria

  Rubric: 3 = add a number to the old password;; 2 = pattern;; 1 = vague;; 0 = none.
• EX039 — Key advantage. Why do security keys resist phishing?
  Show marking criteria

  Rubric: 3 = they check the website;; 2 = site check;; 1 = they are long;; 0 = none.

Synthesis

Usable authentication combines factors in ways that suit staff and resist deception.

Continue studying — chapter 13 of 40

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