You can require passkeys and a second step at sign-in, and an attacker will still walk in through "Forgot password?". Recovery exists for the moment when a person cannot prove who they are in the normal way, so by definition it accepts weaker proof. That weaker proof becomes the real strength of the account.

This post looks at why recovery fails, then at one mechanism in detail: a recovery email, and the rules that stop it becoming a takeover tool.

Why recovery is the weakest door

Sign-in gets the security review. Recovery gets built late, to reduce support tickets. Three things make it dangerous.

  • It bypasses your strongest factors. A flow that resets a password, or removes a second factor, after one emailed link reduces the account to "whoever controls that mailbox".
  • It is rarely used by its owner. A person will not notice that a recovery option was changed.
  • It leaks. Pages that say "we sent a link to j***@example.com" or "no account with that address" tell an attacker which accounts exist and where to aim next.

The attacks follow directly: take over the mailbox and reset everything that points to it, use a brief session to plant your own recovery address, talk an administrator into changing it for you, or brute-force a short code that has no attempt limit.

What a recovery email is for

A recovery email is a second address that can receive a password reset when the person has lost access to their main mailbox. That is a narrow job. It is not a second sign-in identifier, not a contact address, and not something anyone else should be able to see or set. It fixes one failure and adds one risk: a new address that can receive reset links. The rules below keep that risk smaller than the benefit.

Design rules for a recovery email

Only the person sets it

An address chosen by an administrator has never been confirmed by the account holder, and it turns every admin account into a way to redirect resets. Administrators may remove a recovery address, because removal fails safe. They should not be able to add one.

Proven by a code sent to that address

Before an address is stored, send it a code the person must enter. The code needs the usual protections:

  • short lifetime, measured in minutes
  • a small, fixed number of guesses
  • single use
  • bound to the address it was sent to, so a code issued for one address cannot confirm another
  • stored hashed, never in clear text

An unconfirmed address should never receive a reset.

Only from a fresh, complete sign-in

Allow adding or changing a recovery address only shortly after the person authenticated, and only after any second step is complete. A session left open on a shared computer should not be enough. This is a form of step-up authentication.

When a recovery address is added, tell the account's main address at once, and include a one-time "This wasn't me" link. The real owner hears about a planted address and can reverse it.

Undo has to do more than remove the address. Whoever added it had a session, and possibly the password. A proper undo removes the address, ends every session, and forces a password reset through the main address.

A notice might read:

A recovery email was added to your account.

If this was you, there is nothing to do.
If it was not, use the link below within 7 days. It removes the
recovery email, signs out every session and requires a new password.

[This wasn't me]

If the system cannot send that notice, it should refuse to store the recovery address at all.

Removed on password change

A recovery address should not outlive the credential it was set up under. Remove it whenever the password changes, by any route, and tell both addresses. A legitimate user loses a minute setting it again. An attacker loses the recovery path they may have planted.

Never revealed

The address should not be shown in full anywhere: not on the forgot-password page, not in the admin console, not in logs. Mask it where it must appear. The forgot-password page should give the same answer whether or not an account or a recovery address exists.

Rate limits that fail closed

Limit attempts per person, per recipient address and per network address. Without the per-recipient limit, the feature can be used to send unwanted email to a third party. If the limiter itself is unavailable, refuse the request.

What a recovery email cannot do

A recovery email protects someone who has lost access to their own mailbox. It does not protect an account whose own mailbox is controlled by someone else, such as a recycled work address, because the notice and the undo link are sent to that mailbox by design.

It also does not replace stronger options. Layer recovery: a second registered passkey first (see passkeys explained), backup codes stored offline, then a recovery email, with a manual identity check as the last resort.

How AuthFI's recovery email is designed

AuthFI has built a recovery email along these lines. What follows is taken from its design notes, which record two security reviews and that the work had not yet run against live services. Read it as the design, not as a statement about your tenant.

  • Who sets it. Only the person, proven by a 6-digit code sent to the new address. Administrators see it masked, in the form a***@gmail.com, and can remove it. There is no way for an administrator to set one.
  • When it is asked for. After a completed sign-in, including the second step when one is owed. The person can skip, and is asked again after 30 days. It is never offered for federated sign-in.
  • Freshness. Adding or changing is allowed only within 15 minutes of authenticating, and only when the account email is verified.
  • Codes. Stored hashed, bound to the address, valid for 10 minutes, five guesses, single use. Limits apply per person, per recipient address and per IP address, and all fail closed.
  • Forgot password. The same single-use reset link goes to both the account email and the confirmed recovery email. The page never says which addresses exist.
  • Undo. The "added" notice carries a one-time "This wasn't me" link valid for seven days. Using it removes the current recovery email, ends every session and requires that the next password be set only through the emailed reset link. Until then, password and passkey sign-in are both refused.
  • Password change. Every completed password write, whether a reset, a change, a forced change or an admin set, removes the recovery email and tells both addresses.
  • No notice, no storage. If the notice and undo link cannot be sent, the address is not stored.
  • Record. Replacing an address tells the old one. Audit entries and logs carry only the masked address.

The notes state the same limit: it cannot protect an account whose own mailbox is hostile.

Key takeaways

  • An account is as strong as its recovery path, so review recovery with the same care as sign-in.
  • A recovery email should be set only by the person, proven by a code, and added only from a fresh, complete sign-in.
  • Notify the main address with an undo link that removes the address, ends sessions and forces a reset.
  • Remove the recovery email on every password change, and never reveal it.
  • Layer recovery: second passkey first, recovery email after, manual checks last.