Passwords, MFA, passwordless, SSO, and least privilege — the defences that decide who gets in and what they can do.
Authentication = proving who you are (Chapter 8's AuthN). Access control = deciding what you can do once authenticated (AuthZ). Passwords alone are not enough in 2026 — MFA is the baseline. Passwordless (passkeys, hardware keys) is becoming the future. SSO lets users log in once across many apps. Least privilege keeps damage contained when things go wrong. Authentication is the most-attacked surface — phishing, credential stuffing, and brute force all target this layer.
13.1 Why Authentication Is the Battlefield
Stolen and reused credentials are behind the majority of breaches worldwide. The Verizon Data Breach Investigations Report has found, year after year, that compromised credentials appear in 60%+ of confirmed breaches. Every major incident we've covered — Optus, Medibank, Colonial Pipeline — started or was enabled by a credential issue.
This is why authentication gets its own chapter even though we introduced it in Chapter 8. Getting authentication right isn't just one security control among many — it's the control that most attacks try to bypass first.
CONNECTION TO MEDIBANK: Remember — the 2022 Medibank attack started with compromised credentials of an IT contractor. There was no MFA on that account. Once in, the attacker moved laterally through the environment (authorisation failure). An MFA-protected account would have stopped the attack at step one. That single control, applied properly, would have changed the outcome. In exam terms: a single authentication failure enabled a cascading breach.
Passwords are the oldest and most common authentication method. They're also the weakest.
How passwords fail
Failure mode
How it works
Phishing
User tricked into typing their password into a fake site
Credential stuffing
Attackers use passwords leaked from one site to log into others (because people reuse them)
Brute force
Attacker tries millions of guesses. Fast if the site has no rate limiting or MFA.
Dictionary attacks
Trying common passwords first — "Password1", "iloveyou", "123456"
Keylogger malware
Records your keystrokes and sends your password to the attacker
Shoulder surfing
Someone watches you type it
Database breaches
Stolen password databases are cracked offline using GPU farms
Good password practices — updated for 2026
Password guidance has changed significantly. The old rules ("change every 90 days, mix symbols and numbers") are no longer considered best practice — they led to users writing passwords down and picking predictable variations like Password1!, Password2!.
CURRENT BEST PRACTICE (per NIST SP 800-63B, adopted widely):
— Length over complexity — a long passphrase is stronger than a short complex one. "correcthorsebatterystaple" is far stronger than "P@ss1".
— Don't force frequent rotation — only rotate if there's evidence of compromise.
— Block known-compromised passwords — check new passwords against databases of leaked ones (Have I Been Pwned's API is used for this).
— Use a password manager — generate unique long random passwords for every site, store them encrypted, auto-fill.
— Never reuse passwords across sites — especially not between work and personal accounts.
TRAP: Don't recommend "change passwords every 30 days" in an exam answer — it's outdated advice. Current guidance is to rotate only after a suspected breach. Forcing frequent rotation leads to worse passwords, not better ones.
13.3 Multi-Factor Authentication (MFA) — The Baseline
MFA requires proof from two or more different categories of authentication factor (from Chapter 8):
Something you know — password, PIN
Something you have — phone (authenticator app, SMS), hardware token, smart card
Something you are — fingerprint, face, iris
Somewhere you are — GPS location, network location (sometimes a secondary factor)
The point: an attacker needs to compromise two different kinds of thing to impersonate you. Stealing just your password isn't enough if you also need to approve a push notification on your phone.
MFA factor strength — not all methods are equal
This is critical for exam answers. Students often treat "MFA" as a single thing; actually the method matters a lot.
If email is compromised, so is this — circular security
Authenticator apps (Google Authenticator, Authy, Microsoft Authenticator)
⭐⭐⭐ Good
Still phishable — user types code into fake site
Push notifications
⭐⭐⭐ Good (with number matching)
"MFA fatigue" attacks — spam pushes until user taps approve
Hardware security keys (YubiKey, Google Titan — FIDO2/WebAuthn)
⭐⭐⭐⭐⭐ Strongest
User must carry it; loss is annoying
Biometrics on a trusted device (Face ID, Touch ID)
⭐⭐⭐⭐ Strong
Device-bound; doesn't help if logging in elsewhere
HARDWARE KEYS ARE PHISHING-RESISTANT: FIDO2 hardware keys use origin binding — they only produce a valid response for the exact domain the user is logging into. If a user is phished into a lookalike domain, the key won't work — the attacker can't capture a reusable credential. This is why Google rolled out hardware keys for all employees in 2017 and reportedly had zero successful phishing attacks against employees afterwards. The ACSC Essential Eight recommends MFA, and increasingly recommends phishing-resistant MFA where possible.
MFA fatigue — the new attack pattern
Push-based MFA is strong when implemented right, but there's a social engineering twist: attackers use stolen passwords to trigger repeated push notifications to the victim's phone, often in the middle of the night. Eventually the user taps "Approve" just to stop the noise.
The 2022 Uber breach used this technique — the attacker spammed the victim with pushes and then messaged them on WhatsApp pretending to be IT support saying "just approve the prompt so we can complete the upgrade."
Defence:Number matching — the login screen shows a number that the user must type into the app, not just tap approve. Also push rate-limiting and user awareness training.
13.4 Passwordless — Where Authentication Is Heading
Passwordless authentication removes passwords from the equation entirely. The idea: prove your identity via something you have (a registered device with cryptographic keys) and something you are (biometric unlocking that device), with no knowledge-based shared secret.
Passkeys — the current standard
A passkey is a unique asymmetric keypair (Chapter 12!) stored in your device's secure hardware. When you sign in:
The website sends a cryptographic challenge
Your device asks you to confirm via biometric or PIN (something you are)
Your device signs the challenge with your private key (something you have)
The site verifies the signature against your registered public key
What this gives you:
No password to forget, leak, or phish
Unique keypair per site — leaking one site's public key tells attackers nothing about your other accounts
Phishing-resistant — the passkey is bound to the real domain, can't be used on fake ones
Works across devices via cloud sync (iCloud Keychain, Google Password Manager)
Passkeys are actively rolling out across Google, Apple, Microsoft, and many major services in 2024-2026. They're the strongest mainstream authentication method available today and are what Anthropic, Google, and the ACSC recommend for new systems.
13.5 Single Sign-On (SSO)
SSO lets users authenticate once to one trusted identity provider, then access many applications without logging in again. The identity provider vouches for the user to each app.
You've used SSO many times. "Sign in with Google" or "Sign in with Microsoft" are consumer-facing SSO. In a business, every Microsoft 365 or Google Workspace login is an SSO login.
SSO protocols to know (by name)
Protocol
Used for
SAML
Enterprise SSO — a business logs into many third-party apps via a central identity provider (Okta, Azure AD)
OAuth 2.0
Delegated access — "allow App X to access my Google Calendar." Also widely used for general SSO.
OpenID Connect (OIDC)
Modern SSO built on top of OAuth 2.0 — the "sign in with Google" pattern
Kerberos
Internal enterprise authentication, used extensively on Active Directory networks
Pros and cons of SSO
Pro
Con
Fewer passwords to remember → fewer reused passwords
The SSO provider is a single point of failure — if compromised, every connected app is compromised
Easy offboarding — disable one account, access to all apps is revoked
If SSO is down, users can't log into any connected app
Centralised MFA enforcement
Requires trust in the identity provider
Centralised audit logs across all connected apps
Setup complexity — not trivial for small organisations
NET EFFECT: For organisations, SSO + MFA is almost always a net security win. It replaces many weak passwords with one strong account that's centrally managed and monitored. The ACSC Essential Eight recommends restricting admin privileges and implementing MFA — SSO is the common way to do this across a whole organisation.
13.6 Authorisation — After You're In
Authentication proves who you are. Authorisation controls what you're allowed to do. From Chapter 8:
Model
How access is decided
Typical use
RBAC (Role-Based)
Permissions attached to roles; users assigned roles
Most common in organisations
ABAC (Attribute-Based)
Permissions based on attributes (time, location, device, data sensitivity)
Sophisticated environments; cloud access policies
DAC (Discretionary)
Owner of a resource decides
Personal file sharing, Google Drive
MAC (Mandatory)
System enforces classifications
Government, military
Least privilege — the control that makes everything else work
The single most important authorisation principle: every user and every process has only the minimum permissions needed.
Why it matters: it contains the blast radius of any compromise. If an attacker compromises a low-privilege account, they can only do what that account could do. They can't suddenly delete all backups, read every customer's records, or take over the domain controller — because the account they stole never had those permissions in the first place.
Least privilege applies to:
User accounts — a salesperson doesn't need access to the engineering code repository
Admin accounts — admins should use a separate account for admin tasks, not their daily account. Admin privileges only when needed.
Service accounts — the web app's database user can only read certain tables, not DROP TABLE
Network access — the guest Wi-Fi VLAN can't reach the server VLAN (Chapter 14)
Time-based access — elevated access granted just-in-time and expires automatically
THE MEDIBANK FIX, PUT SIMPLY: If MFA had been on the IT contractor's account, the initial credential compromise wouldn't have worked. If least privilege had been applied rigorously, even with credentials, the attacker couldn't have freely moved between systems. The two controls — MFA + least privilege — together would likely have prevented or massively contained the breach. Both exist; neither is exotic. What's missing is consistent implementation.
13.7 Separation of Duties & Just-in-Time Access
Two more principles that build on least privilege:
Separation of duties
No single person should be able to do a highly sensitive action alone. Example: the developer who writes code for the payment system shouldn't also be the person who deploys it to production. That would let them sneak a backdoor in. Have one person write, another review, another deploy.
Used in: financial transactions (one person raises an invoice, another approves it), code deployment, access provisioning.
Just-in-Time (JIT) access
Instead of giving admins permanent elevated privileges, grant them only when needed and expire automatically. Example: an admin needs to restart a server; they request elevation, it's approved (maybe automatically, maybe by a colleague), they have admin rights for 60 minutes, then access reverts. Every elevation is logged.
This drastically reduces the attack surface. "Standing admin privilege" — always-on admin rights — is what makes account compromise catastrophic. JIT limits the window.
13.8 Session Management
Once you're logged in, the system maintains a session — a short-lived token proving you've authenticated. Sessions have their own security considerations:
Session expiry — old sessions should eventually time out, especially on shared devices
Secure transport — session tokens must travel over HTTPS, never HTTP (otherwise they're stealable)
HttpOnly cookies — session cookies marked HttpOnly aren't accessible to JavaScript, limiting XSS damage
Token rotation — some systems rotate session tokens periodically to limit damage from a stolen token
Logout — actually invalidates the session on the server, not just clears the cookie
TRAP: A common bug — an app sets a session cookie without the Secure flag, meaning the browser will send it over plain HTTP too. A MITM on Wi-Fi grabs the cookie, and instantly has your session. Any serious web app must mark session cookies Secure and HttpOnly at minimum, and ideally use SameSite restrictions to limit CSRF.
Accounts aren't static. A complete authentication story covers:
Stage
What must happen
Onboarding
New user verified, account created with least-privilege defaults, MFA enrolled, initial credentials delivered securely
Role changes
When someone changes jobs internally, old permissions are removed and new ones added. Often skipped — leads to "permission accumulation."
Periodic review
Regular access reviews confirm everyone still needs the access they have
Offboarding
When someone leaves, all access revoked immediately — accounts disabled, hardware keys returned, SSO disabled, API keys rotated
Why offboarding matters: Surveys consistently find that 20-40% of former employees retain some access to their old employer's systems months after leaving. This is one of the most preventable breach patterns, and one of the most common causes of insider-triggered incidents. Every dismissal or resignation should trigger an offboarding checklist — otherwise the ex-employee's account becomes a dormant but active entry point.
13.10 Designing Authentication for a Scenario
In a scenario question, a complete authentication design covers:
Identity source — where are users' identities stored? (Active Directory, cloud identity provider, custom database?)
Authorisation model — RBAC / ABAC / DAC / MAC as appropriate
Privilege management — least privilege, separate admin accounts, JIT access
Session handling — timeouts, secure cookies
Lifecycle — onboarding/offboarding process
Monitoring — what counts as suspicious login activity and who gets alerted
EXAM TEMPLATE ANSWER for "design authentication for [scenario]":
"Users authenticate via [identity provider] using [password + MFA / passkeys]. MFA is enforced for all users; administrators must use phishing-resistant MFA (hardware keys). Access permissions follow RBAC, with each role granted minimum necessary privileges (principle of least privilege). Administrators use separate accounts for admin work, with standing privileges removed and granted just-in-time via approved request. Sessions expire after [time] of inactivity and are invalidated on logout. Accounts are provisioned via a formal onboarding process and fully revoked on offboarding, with quarterly access reviews to catch permission drift. Failed logins, unusual geography, and impossible-travel patterns generate alerts for the security team to review."
Covers all 7 areas above = maximum marks.
13.11 Quiz Time
Why is SMS-based MFA considered the weakest form of MFA?
Two main reasons:
1. SIM-swap attacks — attackers socially engineer mobile carriers to transfer the victim's phone number to an attacker-controlled SIM. Calls and SMS then arrive at the attacker, including MFA codes.
2. Phishability — a victim on a convincing phishing site will type their code into the fake site, which the attacker immediately relays to the real site. Push-based and hardware-key MFA are much harder to phish (push requires user action on their own device; hardware keys use origin binding).
SMS is still vastly better than no MFA, but authenticator apps or hardware keys are preferred where available. The ACSC advises moving beyond SMS where possible.
A user argues "MFA is annoying and I shouldn't have to use it for my work email." How would you explain why it's needed, in terms of risk?
Your email account is the single biggest authentication surface most people have. Anyone with access to your email can trigger password resets for every other account linked to that email — banking, social media, cloud storage. Recovering from an email takeover is catastrophic.
In risk terms: the impact of an email takeover is extremely high (access to potentially every other account), and the likelihood of phishing or password reuse leaking a single email password is moderate-to-high. Risk = Likelihood × Impact = a clearly unacceptable number unless something reduces either factor.
MFA reduces likelihood dramatically — an attacker with your password alone can't access the account. The 30 seconds of friction per login is an excellent trade against the cost of an email takeover incident. In exam terms: MFA is the single most cost-effective authentication control for the risk it addresses.
Explain the difference between authentication, authorisation, and session management using a nightclub analogy.
Authentication = the bouncer checking your ID at the door. Establishes who you are. Authorisation = wristband colours that determine which rooms you can enter. VIP gets backstage; general admission stays on the main floor. Session management = once you're inside, the club doesn't re-check your ID every time you move — your wristband is your session. But if you leave the venue, the wristband expires; re-entry requires re-authentication. If you lost the wristband, someone else could impersonate you. That's why sessions are time-limited and can be revoked.
All three have to work together for a proper access control system.
A company discovers that an IT contractor's credentials have been compromised. What immediate and long-term actions should they take?
Immediate:
— Disable the compromised account
— Force logout of all sessions tied to that account
— Review logs for suspicious activity from that account — data accessed, commands run, new accounts created
— Rotate any shared credentials, API keys, or service account passwords the contractor had access to
— Alert the security team / incident response (Chapter 15)
Longer-term (structural) fixes:
— Enforce MFA on all contractor and admin accounts (should already be done — often the root cause of initial compromise)
— Review what access that contractor actually needed and apply least privilege
— Move admin privileges to just-in-time grants rather than standing access
— Review offboarding and contractor-exit processes
— Check for lateral movement from that account's sessions — was anything else accessed that suggests broader compromise?
This is essentially the Medibank aftermath playbook. If the NDB scheme applies (personal info disclosed with risk of serious harm), OAIC notification is required within 30 days.