Authentication and identity

The three factors

Authentication proves a claimed identity using one or more factors, traditionally three categories:

• Something you know: password, PIN, security question.
• Something you have: phone, hardware token, smart card.
• Something you are: biometrics: fingerprint, face, iris.

(Sometimes extended with somewhere you are (location) and something you do (behaviour).)

Multi-factor authentication (MFA) combines factors from different categories. Two passwords are not MFA; a password plus a phone code is. The strength comes from the categories being independent: stealing your password doesn't get the attacker your phone. MFA is the single most effective control against the credential attacks that dominate real breaches, which is why "turn on MFA" is the most repeated practical advice in security.

Not all second factors are equal: SMS one-time codes are better than nothing but weak, being vulnerable to SIM-swapping and interception, which is why NIST SP 800-63-4 restricts SMS as an out-of-band authenticator. TOTP apps (the rotating 6-digit codes) are stronger; FIDO2/WebAuthn hardware security keys and passkeys are the strongest, because they're phishing-resistant: the key cryptographically checks the site's origin, so a fake login page gets nothing.

Password attacks

Even with good storage (salting + Argon2id, from the hashing chapter), passwords get attacked at the point of use:

• Brute force: trying all combinations; defeated by length and rate limiting.
• Dictionary attack: trying likely words and known passwords rather than all combinations.
• Credential stuffing: replaying username/password pairs leaked elsewhere; works because of reuse. MFA and breached-password screening defeat it.
• Password spraying: trying one common password against many accounts, staying under per-account lockout thresholds. A favourite against AD.
• Rainbow tables: precomputed hash-to-password lookups, defeated entirely by per-user salts.
• Phishing / keylogging: capturing the password directly, bypassing its strength entirely. Phishing-resistant MFA is the answer.

The modern guidance (NIST SP 800-63-4) is worth restating because it overturned old habits: prioritise length (≥15 chars single-factor, support long passphrases), screen against breach blocklists, don't force periodic rotation (change only on compromise), drop composition rules, and rate-limit guessing. Long, unique, never-reused passwords in a password manager plus MFA is the practical recipe.

Access control models

Once authenticated, authorisation decides what you can do. The models are a standard exam set:

Model	Decision based on	Example
DAC (Discretionary)	The resource owner's choice	Unix file permissions; share a doc you own
MAC (Mandatory)	A central, system-enforced policy of labels/clearances	Military classification; SELinux
RBAC (Role-Based)	The role assigned to the user	"Nurse" role grants ward records access
ABAC (Attribute-Based)	Attributes of user, resource, context	"Allow if dept=finance AND time is work hours AND on-network"

RBAC is the most common in business systems (assign permissions to roles, roles to people) because it scales and is auditable. ABAC is more granular and flexible (and underlies much zero-trust policy) at the cost of complexity. MAC is the strict, non-overridable model for high-security contexts. Note that MAC the access-control model, the MAC address (networking), and the message-authentication code (crypto) are three entirely different things.

Single sign-on and federation

Users hate logging in repeatedly, and password reuse across many apps is a risk, so single sign-on (SSO) lets one authentication grant access to many services. The enabling protocols:

• SAML: XML-based, long established in enterprise web SSO.
• OAuth 2.0: an authorisation framework that lets an app get delegated access to resources (e.g. "let this app read your calendar") without sharing your password. Note that OAuth is about authorisation/delegation, not authentication on its own. This is a classic point of confusion.
• OIDC (OpenID Connect): an authentication layer built on top of OAuth 2.0, adding identity (the ID token); this is what "Sign in with Google" actually uses.

The benefit is fewer credentials and centralised control (disable one account, lose access everywhere). The risk is concentration: the identity provider becomes a single point of failure and a high-value target, so it must be protected with strong MFA.

Quick recall

• Factors: know / have / are. MFA mixes different categories. Phishing-resistant FIDO2/passkeys > TOTP > SMS (SMS is restricted by NIST).
• Password attacks: brute force, dictionary, credential stuffing (reuse), spraying (one password, many accounts), rainbow tables (beaten by salt), phishing.
• Models: DAC (owner decides), MAC (central policy, non-overridable), RBAC (by role, most common), ABAC (by attributes, zero-trust-friendly).
• SSO: SAML and OIDC do authentication; OAuth 2.0 does delegated authorisation, with OIDC layered on top for identity. The IdP is a concentrated high-value target.