Authentication Methods

Traditional approach (90-day expiry + complexity):
  └─ Users create: Passw0rd!1 → Passw0rd!2 → Passw0rd!3 (predictable patterns)
  └─ Users write down passwords (too many to remember)
  └─ Users reuse similar passwords across sites
  └─ Result: WEAKER security, more support tickets

Modern approach (no expiry + breach check):
  └─ Users create: correct-horse-battery-staple (long, memorable)
  └─ Users with password managers generate: aB7#kL9$xQ2&mR4 (truly random)
  └─ Breach checking prevents reuse of compromised passwords
  └─ Result: STRONGER security, fewer support tickets

OFFICE WORKER WITHOUT PASSWORD MANAGER:
- Has 50+ accounts
- Reuses 3 passwords across all accounts
- One breach at a minor site exposes all accounts
- Average time to reset forgotten password: 10 minutes

OFFICE WORKER WITH PASSWORD MANAGER:
- Has 50+ unique, randomly generated passwords
- Only needs to remember 1 master password
- A breach at one site affects only that account
- Time to log into any account: 3 seconds (autofill)

MFA Fatigue Attack:
  1. Attacker obtains user's password (phishing, credential stuffing)
  2. Attacker attempts to log in, triggering push MFA notification
  3. Attacker sends MULTIPLE push notifications rapidly (10-50 in minutes)
  4. User gets annoyed and accidentally taps "Approve"
  5. Attacker gains access

Mitigation:
  └─ Number matching: User must enter the number shown on screen
  └─ Geo-fencing: Only allow MFA push from expected locations
  └─ Rate limiting: Max 3 MFA push attempts per 5 minutes
  └─ Phishing-resistant MFA: Hardware keys or passkeys (immune to fatigue)

// WebAuthn registration (browser)
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: new Uint8Array([/* server-generated challenge */]),
    rp: { name: "Example Corp" },
    user: {
      id: new Uint8Array([/* user ID */]),
      name: "user@example.com",
      displayName: "User Johnson"
    },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }] // ES256
  }
});

// WebAuthn authentication
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: new Uint8Array([/* server-generated challenge */]),
    allowCredentials: [{ id: credentialId, type: "public-key" }]
  }
});

Passkey Architecture:
  └─ Private key: Stored on user's device (Secure Enclave, TPM, Keychain)
  └─ Public key: Stored on server
  └─ Authentication: Device proves possession of private key
  └─ Sync: iCloud Keychain (Apple), Google Password Manager (Android), Windows Hello (Microsoft)

Platform Support:
  └─ Apple: iOS 16+, macOS 13+ (Safari, iCloud Keychain sync)
  └─ Google: Android 9+, Chrome (Google Password Manager sync)
  └─ Microsoft: Windows 11, Edge (Windows Hello)
  └─ Third-party: 1Password, Bitwarden, Dashlane (cross-platform)

Enterprise Considerations:
  └─ Platform passkeys: Free, but tied to device ecosystem
  └─ Cross-platform: Third-party providers offer roaming passkeys
  └─ Recovery: Lost device → lose passkey → need account recovery flow
  └─ Hardware-backed: YubiKey Bio, Samsung Pass

User → Accesses SP (Service Provider, e.g., Salesforce)
    → SP redirects to IdP (Identity Provider, e.g., Okta)
    → User authenticates at IdP
    → IdP issues SAML assertion
    → Browser posts SAML assertion to SP
    → SP validates assertion → User is logged in

OAuth 2.0:
  Resource Owner (User) → Authorises Client (App) → Gets Access Token
  → Client uses Access Token to access Resource Server (API)

OpenID Connect (adds):
  + ID Token (JWT containing identity claims)
  + UserInfo endpoint (standardised user attributes)

SSO Risks:
  └─ IdP compromise = compromise of ALL connected applications
  └─ SAML assertion validation bugs (XML signature wrapping attacks)
  └─ OAuth token theft (access token in browser, CSRF, redirect URI manipulation)
  └─ Shadow admin: Users with IdP admin rights can access any application

SSO Hardening:
  └─ IdP: Strong access controls on IdP admin console (separate admin accounts)
  └─ SAML: Validate signature + assertion + audience + recipient + NotOnOrAfter
  └─ OAuth: PKCE (Proof Key for Code Exchange) for all public clients
  └─ Token: Short access token lifetimes (15-60 minutes), refresh token rotation

def calculate_authn_risk(request):
    risk_score = 0

    # Location
    if request.geo_country not in ["US", "CA", "GB"]:
        risk_score += 30
    if request.geo_distance_from_last > 500:  # km
        risk_score += 20

    # Device
    if not request.device_is_managed:
        risk_score += 25
    if request.device_os_version < MINIMUM_VERSION:
        risk_score += 15

    # Behaviour
    if request.time_local.hour < 6 or request.time_local.hour > 22:
        risk_score += 10
    if request.ip_is_anonymous_vpn:
        risk_score += 40
    if request.user_agent_is_unusual:
        risk_score += 15

    # Decision
    if risk_score < 20:
        return "Allow — no MFA required"
    elif risk_score < 50:
        return "Allow — require MFA"
    elif risk_score < 80:
        return "Challenge — require phishing-resistant MFA"
    else:
        return "Block — deny access, alert SOC"

RBA Best Practices:
  └─ Start permissive: Log risk score without enforcement (discover patterns)
  └─ Add step-up MFA: Only challenge high-risk sessions
  └─ Monitor false positives: Users getting challenged for legitimate access?
  └─ Context matters: A login from a known VPN provider is different from a known anonymiser
  └─ Session risk: Re-evaluate risk during session (not just at login)
  └─ Feedback loop: Approved high-risk sessions should reduce future challenges

Common RBA Signals:
  └─ Impossible travel: Login from NYC → login from Tokyo in 10 minutes
  └─ Anonymous IP: VPN, Tor, proxy, data centre IP
  └─ New device: First time this device has authenticated
  └─ Suspicious behaviour: Rapid-fire API calls, unusual data access patterns
  └─ Credential stuffing indicators: Same username, many IPs; same IP, many usernames

Phase 1 — Reduce password reliance:
  └─ Deploy SSO (reduce number of passwords)
  └─ Enforce MFA (add second factor)
  └─ Deploy password manager (handle complex passwords)

Phase 2 — Introduce passwordless options:
  └─ Enable Windows Hello / Face ID for corporate devices
  └─ Deploy FIDO2 security keys for privileged users
  └─ Enable passwordless for low-risk applications first

Phase 3 — Eliminate passwords:
  └─ Require passkeys for all internal applications
  └─ Remove password-based login for privileged accounts
  └─ Implement recovery flow (lost device → verified identity → new passkey)