Template

Files

Danijel Martinek f77e6ea881 chore(template): clean-slate template snapshot from bb4a0c7

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

2026-07-12 20:40:54 +02:00

4.7 KiB

Raw Blame History

status, playbook-section, title, last-reviewed

status	playbook-section	title	last-reviewed
template	40	Password & Authentication Policy	[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 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).

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].

4.7 KiB Raw Blame History