Account Recovery

Strong MFA doesn't do much good if an attacker can bypass it through an easier recovery path. Account recovery restores control after a user loses the authenticators needed to sign in, and it has to answer a tough question:

How do we restore access without making it easy for attackers to exploit the recovery process?

Email recovery is not automatically insecure. A strong, short-lived recovery code sent to a previously verified address can be appropriate in some cases. But an email-only bypass can be too weak for a high-risk account.

Attackers know this, so they target recovery flows directly. Recovery has to balance:

1. Safety: Don't let attackers gain access
2. Usability: Don't permanently lock out legitimate users

Alternatives to email recovery include:

• Saved recovery codes: Random secrets issued during enrollment and stored offline by the user
• Recovery contacts: Prearranged contacts (like an organization admin) that participate in recovery
• Repeated identity proofing: Repeating enough of the original identity checks to establish that the claimant matches the identity tied to the account

Assignment

Backup codes are supposed to be single-use, but the app never marks them as used.

Make checking and consuming a backup code one atomic database operation.

1. In internal/auth/mfa/store.go, update Store.ConsumeBackupCode to call the pre-generated ConsumeTOTPBackupCode query. Return true only when the update consumes one unused code.
2. Start the app.

With Bearly Secure still running, run and submit the CLI tests from the project root.