Chapter 7 — Networks and protocols | Bachelor's Identity and access management

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 7 — Networks and protocols

Lesson map

Lesson 07 published. Map, example, EX019.

flowchart TD
  N0["Learning outcomes"]
  N1["7.1 Signing in over the internet"]
  N2["7.2 Single sign-on"]
  N3["7.3 Fake sign-in pages"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX019"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["7.1 Signing in over the internet"]
  N2["7.2 Single sign-on"]
  N3["7.3 Fake sign-in pages"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX019"]

[Learning outcomes]
    |
    v
[7.1 Signing in over the internet]
    |
    v
[7.2 Single sign-on]
    |
    v
[7.3 Fake sign-in pages]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX019]

Learning outcomes

You will (1) explain how sign-in travels over the internet; (2) describe HTTPS and why it matters; (3) recognise fake sign-in pages.

7.1 Signing in over the internet

When a Greenhill employee signs in to the office suite, the browser sends their username and authentication to the provider's servers across the internet. HTTPS protects this traffic using TLS, which encrypts it and confirms the server's identity through a certificate. Without HTTPS, anyone on the same network, such as public Wi-Fi in a café, could read passwords. Elena checks that every system Greenhill uses for sign-in uses HTTPS, and finds that all do, including the older finance system after a recent upgrade.

7.2 Single sign-on

Some Greenhill systems trust the office suite to sign staff in. The browser is sent to the office suite's sign-in page, the user signs in there and is sent back to the system with a signed message saying who they are. Standards such as SAML 2.0 and OpenID Connect describe how these messages work. The benefit for Greenhill is one place to sign in, enforce multi-factor authentication and disable access, rather than a separate password for each system that must be managed and removed separately.

7.3 Fake sign-in pages

Attackers create pages that look like the real sign-in page to capture what people type. Staff are taught to check the address bar, but that is unreliable under pressure. Stronger protection comes from authenticators that only work with the real site, such as passkeys based on the W3C WebAuthn standard, which will not respond to a look-alike address. Elena explains this to Greenhill managers as the reason to prefer passkeys or security keys over codes typed from a phone, especially for finance and administrator accounts.

Worked example

Elena confirms HTTPS on all six systems and identifies three that could use the office suite for single sign-on, reducing separate passwords.

Synthetic case. Systems and findings are synthetic; SAML 2.0, OpenID Connect and WebAuthn are real standards.

Errors and limits

Relying only on staff spotting fake addresses ignores how convincing look-alike pages can be under time pressure.

Exercises

EX019 — HTTPS role. What does HTTPS do for sign-in? Rubric: 3 = encrypts traffic and confirms server identity;; 2 = encrypts;; 1 = speeds up;; 0 = none.
EX020 — SSO benefit. What is Greenhill's main benefit from single sign-on? Rubric: 3 = one place to sign in, enforce MFA and disable access;; 2 = central control;; 1 = vague;; 0 = none.
EX021 — Fake page defence. Which authenticators resist fake sign-in pages? Rubric: 3 = site-bound passkeys or security keys (WebAuthn);; 2 = passkeys;; 1 = SMS codes;; 0 = none.

Synthesis

HTTPS protects sign-in traffic, single sign-on centralises control, and site-bound authenticators resist fake pages.

Continue studying — chapter 07 of 40

← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →