Danijel Martinek
f77e6ea881
Curated, product-agnostic snapshot of the post-story-04 tree: demo content deleted, auth-only reference feature, web-next shell, all gates green. Product-specific docs, ADRs 027-029, PRDs/epics/archive, editor library traces, and product naming are curated out; generic template repairs (coverage provider devDeps, root test:coverage script, live lint fixes, root-only release-please) are kept. See TEMPLATE.md for provenance, curation list, and usage. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016j8z4VHjedXDTjEDNg7qHK
83 lines
4.7 KiB
Markdown
83 lines
4.7 KiB
Markdown
---
|
|
status: template
|
|
playbook-section: 40
|
|
title: "Password & Authentication Policy"
|
|
last-reviewed: "[FILL IN: YYYY-MM-DD]"
|
|
---
|
|
|
|
# Password & Authentication Policy
|
|
|
|
> **Template status** — fill every `[FILL IN: …]` marker before use.
|
|
|
|
> **Not code-enforced** — MFA enforcement, minimum password complexity, and account lockout are **explicitly deferred** in [ADR-025 § Deferred items](../../decisions/adr-025-eu-compliance-baseline.md) because they require identity-infrastructure choices (TOTP/WebAuthn/passkeys), a threat-model-specific policy, and an OTP delivery vendor that are consumer-supplied. This template documents the policy; the consumer implements the technical controls once those choices are made.
|
|
|
|
---
|
|
|
|
## 1. Purpose & Scope
|
|
|
|
This policy defines the minimum authentication standards for all accounts — human and service — that access systems operated by `[FILL IN: organisation name]`, including `[FILL IN: describe systems — e.g., the application, Payload CMS, cloud infrastructure consoles, CI/CD pipelines]`.
|
|
|
|
**Owner:** `[FILL IN: role — e.g., Head of Engineering / CISO]`
|
|
|
|
---
|
|
|
|
## 2. Password Requirements
|
|
|
|
### 2.1 User accounts
|
|
|
|
| Requirement | Minimum standard | Organisation value |
|
|
| ----------------------- | ------------------------------------------- | ------------------------------ |
|
|
| Minimum length | 12 characters | `[FILL IN:]` |
|
|
| Character complexity | No single-class requirement; length > rules | `[FILL IN: any additions]` |
|
|
| Breach / pwned-password | Must be checked on creation / change | `[FILL IN: tool / service]` |
|
|
| Maximum age | Not enforced unless breach detected | `[FILL IN: or "not enforced"]` |
|
|
| Reuse restriction | `[FILL IN: e.g., last 10 passwords]` | `[FILL IN:]` |
|
|
|
|
> Reference: NIST SP 800-63B §5.1.1 — length beats complexity rules; mandatory rotation is discouraged.
|
|
|
|
### 2.2 Service accounts & API secrets
|
|
|
|
- All service secrets are stored in `[FILL IN: secret manager — e.g., AWS Secrets Manager / HashiCorp Vault]`.
|
|
- Secrets are rotated `[FILL IN: frequency — e.g., every 90 days or on suspected compromise]`.
|
|
- Long-lived credentials are prohibited for `[FILL IN: list systems — e.g., production database, CI/CD pipelines]`.
|
|
|
|
---
|
|
|
|
## 3. Multi-Factor Authentication (MFA)
|
|
|
|
> **Deferred per ADR-025.** The specific MFA method (TOTP, WebAuthn, SMS) and the enforcement perimeter are consumer decisions. Until those choices are made, document the target state here.
|
|
|
|
| Account type | Required MFA method | Enforcement date / trigger |
|
|
| ------------------------------ | ---------------------------- | -------------------------- |
|
|
| Admin / privileged users | `[FILL IN: e.g., WebAuthn]` | `[FILL IN: YYYY-MM-DD]` |
|
|
| All users (application) | `[FILL IN: e.g., TOTP]` | `[FILL IN:]` |
|
|
| Service accounts | N/A — use short-lived tokens | — |
|
|
| Infrastructure / cloud console | `[FILL IN:]` | `[FILL IN:]` |
|
|
|
|
---
|
|
|
|
## 4. Account Lockout & Brute-Force Protection
|
|
|
|
> **Deferred per ADR-025.** Lockout thresholds are deferred until the authentication threat model is established. The application ships rate-limit budgets (see `rateLimit` in each feature manifest and ADR-025 § Epic C) but does not hard-lock accounts.
|
|
|
|
| Parameter | Target value | Status |
|
|
| ------------------------------ | ----------------------------------------------- | ---------------------------- |
|
|
| Failed attempts before lockout | `[FILL IN: e.g., 10]` | `[FILL IN: deferred / live]` |
|
|
| Lockout duration | `[FILL IN: e.g., 15 minutes]` | `[FILL IN:]` |
|
|
| Admin unlock procedure | `[FILL IN: e.g., helpdesk ticket + MFA reset]` | `[FILL IN:]` |
|
|
| Notification on lockout | `[FILL IN: e.g., email to user + Sentry alert]` | `[FILL IN:]` |
|
|
|
|
---
|
|
|
|
## 5. Privileged Access
|
|
|
|
- Privileged (admin) access requires `[FILL IN: approval workflow — e.g., pair-approval in #infra-access]`.
|
|
- Privileged sessions are limited to `[FILL IN: duration — e.g., 4-hour session tokens]`.
|
|
- All privileged actions are captured by the audit channel (see [`docs/guides/audit-and-compliance.md`](../../guides/audit-and-compliance.md)).
|
|
|
|
---
|
|
|
|
## 6. Review Cycle
|
|
|
|
This policy is reviewed `[FILL IN: frequency — e.g., annually or after any authentication-related incident]`. The next scheduled review is `[FILL IN: YYYY-MM-DD]`.
|