Files
policies/Security/authentication_guidance.md

174 lines
9.9 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Authentication Guidance & Hardening (Comprehensive, EUAligned)
**Document owner:** [Owner/Role]
**Approved by:** [Steering Committee / CISO]
**Effective date:** [YYYY-MM-DD]
**Review cadence:** [Annually]
---
## 1. Purpose & Scope
This document provides practical guidance and examples for implementing the Authentication Policy across [Organization] systems.
It includes detailed examples for assurance levels, distinction of methods (passwords vs PINs vs biometrics), special cases (BitLocker, local admin accounts), outofband methods, central vs. local authentication, and reauthentication.
---
## 2. Method Identification Guide (What is it? Where does the secret live?)
Use this section to classify any method you encounter.
### 2.1 Memorized Secrets (Passwords)
- **What it is:** A humanchosen **password** sent to a **verifier** (server) that stores only a **hash**.
- **Where the secret lives:** In the **users memory**; verifier stores a **hashed verifier**.
- **Factor category:** **Something you know**.
- **Typical AAL:** **AAL1** alone; **AAL2** when combined with another factor.
- **Examples:** Account password for SSO, VPN, app logins.
- **Notes:** Allow paste/managers; use passphrases; blocklist screening; no composition rules; no periodic expiry.
### 2.2 Activation Secrets (PINs that unlock local authenticators)
- **What it is:** A **PIN** used to unlock a **local cryptographic key** (TPM, smart card, FIDO2). The PIN itself is **never transmitted** to a server.
- **Where the secret lives:** **On the device/token** only (e.g., TPM/smartcard); verifier never sees it.
- **Factor category:** **Something you know** (used locally), combined with **something you have** (device/token).
- **Typical AAL:** Contributes to **AAL2** or **AAL3** depending on hardware and protocol.
- **Examples and distinctions:**
- **Windows Hello PIN** → unlocks TPMbound private key on **that device only**; **not** the same as the account password.
- **Smartcard PIN** → unlocks cards private key; used with certificatebased login.
- **FIDO2 PIN** → unlocks the authenticator to perform WebAuthn challenges.
- **Mobile device screen PIN** → unlocks the phone; when used with a bound authenticator app, it protects the **OOB** channel.
- **BitLocker preboot PIN** → unlocks the disk key (see BitLocker section).
- **Minimums:** PIN **≥4**, **should be ≥6**; local throttling/lockout required.
### 2.3 Biometrics (Local unlock only)
- **What it is:** **Fingerprint/face/iris** used to unlock a **local key** (e.g., Windows Hello, phone biometric).
- **Where the secret lives:** Biometric template stays on the device/TPM/secure enclave.
- **Factor category:** **Something you are** (local unlock).
- **Typical AAL:** Part of **AAL2/AAL3** when combined with hardware key; **never** as sole factor.
### 2.4 OutofBand (OOB) Methods
- **What it is:** A second, **separate channel** (e.g., mobile app) to approve login.
- **Where the secret lives:** Bound to the **mobile device/app**; approvals sent over encrypted channel.
- **Factor category:** Typically **something you have** (the device), sometimes plus its **PIN/biometric** (something you know/are).
- **Typical AAL:** **AAL2** when **devicebound and encrypted**.
- **Examples:** Push approvals; **QRcode signin** with Microsoft Authenticator.
- **Not permitted as primary:** SMS/voice/email (recovery only).
---
## 3. Assurance Levels Examples & Guidance
### 🔹 AAL1 (Single Factor)
- **Examples:**
- Passwordonly login to lowrisk intranet site
- Local Linux/Windows account with password
- BitLocker with **PIN only** (no TPM)
- Local admin password **without LAPS**
- **Risks:** Phishable/replayable; bruteforceable.
- **Guidance:** Use only for lowsensitivity or offline recovery; **not** for remote/external access; plan deprecation.
### 🔹 AAL2 (Standard MFA)
- **Examples:**
- Password + **TOTP** authenticator app
- Password + **push** approval on a bound device
- Password + **QRcode** signin with Microsoft Authenticator
- **Smartcard + PIN**
- **Windows Hello** (TPMbacked key) + PIN/biometric
- **BitLocker: TPM + PIN**
- Local admin password **with LAPS** (unique per device, rotated) for offline recovery scenarios
- **Risks:** Still phishable (push/QR can be proxied).
- **Guidance:** Default for SaaS, VPN, employee desktops; allow push/QR only when **devicebound** and **ratelimited**; enroll **≥2 MFA methods** per user.
### 🔹 AAL3 (High Assurance)
- **Examples:**
- **FIDO2/WebAuthn hardware** security key
- **PIV/smartcard** login with crypto challenge + PIN
- **Windows Hello** with biometric unlocking a **TPMbound** key used for hardwarebacked auth
- **BitLocker: TPM + PIN + postboot FIDO2** login
- **Risks:** Strong phishing and verifierimpersonation resistance.
- **Guidance:** Required for admins, production, regulated systems; **no OOB**; keys must be **nonexportable** and hardwareprotected; biometrics only unlock keys.
---
## 4. Central vs. Local Authentication
- **Central (preferred):** IdP/SSO (SAML/OIDC/RADIUS) with consistent policy, logging, and conditional access.
- **Local (supporting/offline):** BitLocker preboot PIN, Windows Hello PIN, Linux root password.
- **Guidance:** Local methods **must** follow length/blocklist rules for memorized secrets and enforce local throttling; prefer TPM/smartcard integration for higher assurance.
---
## 5. BitLocker PreBoot Authentication (Deepdive)
- **TPM only:** Disk key released automatically → **AAL1**. Not acceptable for sensitive data.
- **PIN only (no TPM):** PIN protects disk key → **AAL1**. Use only with compensating **postboot MFA** and limited roles.
- **TPM + PIN:** PIN unlocks TPM which releases disk key → **AAL2**. Enterprise baseline for laptops.
- **TPM + PIN + postboot FIDO2/smartcard:** Meets **AAL3** for privileged/regulated systems.
- **Operational requirements:** PIN length **≥6** recommended; enforce lockout/antihammering; maintain recovery key hygiene; test preboot accessibility for users with assistive tech.
---
## 6. Local Administrator Accounts
- **Without LAPS:** Shared/static password → **AAL1 (high risk)**; prohibited except as breakglass in a vault with approvals and audit.
- **With LAPS:** Unique random password per device, rotated automatically → **AAL1 (mitigated)**; acceptable for offline recovery; retrieval must be logged.
- **Preferred daily admin:** Central privileged accounts with **MFA** (**AAL2/AAL3**).
---
## 7. Reauthentication & Session Management
- **AAL1:** Reauth **≤ 30 days**.
- **AAL2:** Reauth **≤ 24 hours**, inactivity **≤ 1 hour**.
- **AAL3:** Reauth **≤ 12 hours**, inactivity **≤ 15 minutes**.
- **Tips:** Warn prior to expiry; support seamless reauth with devicebound authenticators.
---
## 8. Password Creation & User Education (Quick Guide)
- Prefer **passphrases** (multiple unrelated words with spaces).
- Avoid personal info, service names, or keyboard patterns.
- Use a **password manager**; unique secret per site/system.
- Expect **blocklist rejection** for weak/compromised choices.
- Do **not** write down passwords in plain sight; if written, store securely.
---
## 9. Quick Comparison Tables
### 9.1 Method Classification
| Method | What it is | Secret location | Factor(s) | Typical AAL | Notes |
|---|---|---|---|---|---|
| Account **password** | Memorized secret sent to verifier | User memory / verifier stores hash | Know | AAL1 (alone) | Needs blocklist; no composition; no expiry |
| **Windows Hello PIN** | Local PIN to unlock TPM key | Device TPM | Know + Have (device) | AAL2AAL3* | Devicespecific; not account password |
| **Smartcard PIN** | Local PIN to unlock card key | Smartcard | Know + Have | AAL2AAL3 | Certbased login |
| **FIDO2 PIN** | Local PIN to unlock FIDO key | Hardware key | Know + Have | AAL3 | Phishingresistant |
| **Biometric** | Local unlock (face/fingerprint) | Device enclave | Are (+ Have) | AAL2AAL3 | Unlock only; not sole factor |
| **TOTP app** | Onetime code generator | Mobile device | Have (+ Know if app PIN) | AAL2 | Bind device; protect seed |
| **Push/QR OOB** | Encrypted approval channel | Mobile device | Have (+ Know/Are) | AAL2 | Devicebound & ratelimited |
| **SMS/voice/email OTP** | Code over PSTN/email | Network/mail | Have? (weak) | Recovery only | Not primary MFA |
\*Depends on deployment: with hardwarebound nonexportable keys and phishingresistant protocol usage, Windows Hello deployments can reach AAL3.
### 9.2 BitLocker Summary
| Mode | AAL | Use Case | Notes |
|---|---|---|---|
| TPM only | AAL1 | Lowrisk fleets | Not for sensitive data |
| PIN only (no TPM) | AAL1 | Legacy/noTPM | Must pair with postboot MFA |
| TPM + PIN | AAL2 | Enterprise baseline | Enforce ≥6 PIN, antihammering |
| TPM + PIN + postboot FIDO2 | AAL3 | Admin/regulated | Strongest posture |
---
## 10. Hardening Checklist
✅ Map systems to **AAL1AAL3**
✅ Enforce **password** rules (length, 64char support, Unicode, blocklist, no composition)
✅ Enroll **≥2 MFA methods** per user (primary + backup)
✅ Prefer **FIDO2/smartcard** for AAL3; ban **OOB** at AAL3
✅ Permit only **devicebound encrypted** push/QR; **ban SMS/email/voice** as primary
✅ Enforce **LAPS** on all Windows endpoints; ban shared local admin passwords
✅ Configure **ratelimiting** for online guesses; local antihammering for PINs
✅ Implement **session timeouts** per AAL; warn users preexpiry
✅ Audit **MFA resets**, **local admin retrievals**, and **failed logins**
---
## 11. References
- NIST SP 80063B (Digital Identity Guidelines, 2023 update)
- CIS Controls v8.1 (Controls 5 & 6)
- ENISA Guidelines on Identity and Access Management
- OWASP Authentication Cheat Sheet