9.9 KiB
9.9 KiB
Authentication Guidance & Hardening (Comprehensive, EU‑Aligned)
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), out‑of‑band 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 human‑chosen password sent to a verifier (server) that stores only a hash.
- Where the secret lives: In the user’s 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/smart‑card); 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 TPM‑bound private key on that device only; not the same as the account password.
- Smart‑card PIN → unlocks card’s private key; used with certificate‑based 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 pre‑boot 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 Out‑of‑Band (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 device‑bound and encrypted.
- Examples: Push approvals; QR‑code sign‑in with Microsoft Authenticator.
- Not permitted as primary: SMS/voice/email (recovery only).
3. Assurance Levels – Examples & Guidance
🔹 AAL1 (Single Factor)
- Examples:
- Password‑only login to low‑risk intranet site
- Local Linux/Windows account with password
- BitLocker with PIN only (no TPM)
- Local admin password without LAPS
- Risks: Phishable/replayable; brute‑forceable.
- Guidance: Use only for low‑sensitivity 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 + QR‑code sign‑in with Microsoft Authenticator
- Smart‑card + PIN
- Windows Hello (TPM‑backed 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 device‑bound and rate‑limited; enroll ≥2 MFA methods per user.
🔹 AAL3 (High Assurance)
- Examples:
- FIDO2/WebAuthn hardware security key
- PIV/smart‑card login with crypto challenge + PIN
- Windows Hello with biometric unlocking a TPM‑bound key used for hardware‑backed auth
- BitLocker: TPM + PIN + post‑boot FIDO2 login
- Risks: Strong phishing and verifier‑impersonation resistance.
- Guidance: Required for admins, production, regulated systems; no OOB; keys must be non‑exportable and hardware‑protected; 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 pre‑boot PIN, Windows Hello PIN, Linux root password.
- Guidance: Local methods must follow length/blocklist rules for memorized secrets and enforce local throttling; prefer TPM/smart‑card integration for higher assurance.
5. BitLocker Pre‑Boot Authentication (Deep‑dive)
- 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 post‑boot MFA and limited roles.
- TPM + PIN: PIN unlocks TPM which releases disk key → AAL2. Enterprise baseline for laptops.
- TPM + PIN + post‑boot FIDO2/smart‑card: Meets AAL3 for privileged/regulated systems.
- Operational requirements: PIN length ≥6 recommended; enforce lockout/anti‑hammering; maintain recovery key hygiene; test pre‑boot accessibility for users with assistive tech.
6. Local Administrator Accounts
- Without LAPS: Shared/static password → AAL1 (high risk); prohibited except as break‑glass 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 device‑bound 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) | AAL2–AAL3* | Device‑specific; not account password |
| Smart‑card PIN | Local PIN to unlock card key | Smart‑card | Know + Have | AAL2–AAL3 | Cert‑based login |
| FIDO2 PIN | Local PIN to unlock FIDO key | Hardware key | Know + Have | AAL3 | Phishing‑resistant |
| Biometric | Local unlock (face/fingerprint) | Device enclave | Are (+ Have) | AAL2–AAL3 | Unlock only; not sole factor |
| TOTP app | One‑time 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 | Device‑bound & rate‑limited |
| SMS/voice/email OTP | Code over PSTN/email | Network/mail | Have? (weak) | Recovery only | Not primary MFA |
*Depends on deployment: with hardware‑bound non‑exportable keys and phishing‑resistant protocol usage, Windows Hello deployments can reach AAL3.
9.2 BitLocker Summary
| Mode | AAL | Use Case | Notes |
|---|---|---|---|
| TPM only | AAL1 | Low‑risk fleets | Not for sensitive data |
| PIN only (no TPM) | AAL1 | Legacy/no‑TPM | Must pair with post‑boot MFA |
| TPM + PIN | AAL2 | Enterprise baseline | Enforce ≥6 PIN, anti‑hammering |
| TPM + PIN + post‑boot FIDO2 | AAL3 | Admin/regulated | Strongest posture |
10. Hardening Checklist
✅ Map systems to AAL1–AAL3
✅ Enforce password rules (length, 64‑char support, Unicode, blocklist, no composition)
✅ Enroll ≥2 MFA methods per user (primary + backup)
✅ Prefer FIDO2/smart‑card for AAL3; ban OOB at AAL3
✅ Permit only device‑bound encrypted push/QR; ban SMS/email/voice as primary
✅ Enforce LAPS on all Windows endpoints; ban shared local admin passwords
✅ Configure rate‑limiting for online guesses; local anti‑hammering for PINs
✅ Implement session timeouts per AAL; warn users pre‑expiry
✅ Audit MFA resets, local admin retrievals, and failed logins
11. References
- NIST SP 800‑63B (Digital Identity Guidelines, 2023 update)
- CIS Controls v8.1 (Controls 5 & 6)
- ENISA Guidelines on Identity and Access Management
- OWASP Authentication Cheat Sheet