4 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 Milne	ae99d3d9cf	Fix webauthn bug. Fix tests. Update docs	2026-01-01 15:24:56 +11:00
Dan Milne	93a0edb0a2	StandardRB fixes	2026-01-01 13:29:44 +11:00
Dan Milne	57abc0b804	Add webauthn	2025-11-04 16:20:11 +11:00