5 Commits

Include renames

Author	SHA1	Message	Date
Dan MilneandClaude Fable 5	44892e3301	Make WebAuthn clone detection actually block, and fix false positives ... Two problems with sign-count clone detection: - suspicious_sign_count? flagged the case where both the stored and presented counts are 0. Most synced passkeys (Apple/Google) report 0 every time, so every legitimate sign-in was flagged — drowning real signals in noise. Per WebAuthn §6.1.1 a 0 counter means "no counter"; only flag when BOTH counts are non-zero and the new one does not advance. - On a suspicious count the controller only logged a warning and then continued to authenticate and overwrite the stored counter. A cloned credential therefore worked indefinitely. webauthn_verify now rejects the sign-in (no session, no counter update) and emails the user via a new SecurityMailer#suspicious_passkey_used. Tests cover the corrected classification (synced/first-use/normal vs equal/ decreasing) and the new alert email. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-06-11 20:28:38 +10:00
Dan MilneandClaude Opus 4.7	cc93f72f0a	Notify users out-of-band when security settings change ... Previously only TOTP-enabled triggered an email. Every other security-relevant change — password change, TOTP disable, passkey add/remove, API key create/revoke, email address change, backup-code regeneration — happened silently, so an attacker on a stolen session could quietly drop 2FA or hijack the email with no signal to the account holder. Add SecurityMailer with one method per event. Each email carries the request IP, user-agent, and timestamp so the user can spot unfamiliar activity. Email-address changes notify both the old and new addresses with directional language; the old-address copy explicitly warns that whoever made the change can now receive password reset emails. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-02 23:52:12 +10:00
Dan MilneandClaude Opus 4	b876e02c3a	Hold TOTP enrollment secret server-side and email user on activation ... TOTP enrollment previously round-tripped the generated secret through a hidden form field and saved whatever the client submitted, letting an attacker with session access enroll a 2FA device they control by posting their own secret plus a matching code. Stash the secret in the session at GET /totp/new, read it only from the session at POST /totp, and drop the hidden field from the view. Notify the user by email on successful enrollment so unauthorized activations are visible even if a new vector appears later. Co-Authored-By: Claude Opus 4 <noreply@anthropic.com>	2026-04-20 18:17:50 +10:00
Dan Milne	56f7dd7b3c	First crack	2025-10-23 16:45:00 +11:00
Dan Milne	1ff0a95392	First commit	2025-10-23 16:19:56 +11:00