Signup, Recovery, and the Account Lifecycle
Signup, verification, recovery, contact changes, and deletion are where most account takeovers actually happen. Design every one of them as carefully as sign-in.
Signup
- Collect the identifier first; ask for a password only if the user does not choose a passkey or social sign-in.
- Create the user in an unverified state. Do not enforce uniqueness on unverified identifiers (Chapter 3).
- Send a verification link or code. Let the user continue into low-risk parts of the product while unverified, if your product allows it.
- Offer a passkey on the first successful sign-in.
If the email already belongs to a verified account, do not say so on screen. Send that address an email instead: "Someone tried to create an account with your email. If it was you, sign in here."
Verification links and codes
| Property | Rule |
|---|---|
| Randomness | At least 128 bits for links; codes of 6 or more digits with attempt limits |
| Storage | Hashed, like passwords |
| Lifetime | Short: minutes for codes, an hour or less for links |
| Use | Single use; invalidate all older tokens when a new one is issued |
| Binding | Bound to the user and the purpose (verify, reset, change email) so one cannot be reused as another |
| Link scanners | Email security scanners click links. Make GET show a confirm button and do the action on POST |
Password reset
- Always show the same response: "If an account exists, we have sent a link."
- Rate-limit by account, by IP, and by destination address.
- On a valid link, let the user set a new password or create a passkey.
- After reset: sign out every session, revoke refresh tokens and remembered devices, and notify all verified contact points.
- If the account has MFA, a reset link alone must not bypass it. Require the second factor or route to recovery.
Recovery when every factor is lost
This is the path attackers aim for once passkeys close the front door. Build it with layers:
- Self-service first: recovery codes, a second passkey, or a verified backup email.
- Waiting period: if the user has none, start a recovery that completes after a delay (for example 24 to 72 hours), notifying every known contact point so the real owner can cancel it.
- Restricted access after recovery: block payout changes, email changes, and factor removal for a period.
- Human support last: a documented verification procedure that cannot be skipped by an agent under pressure, with every override logged and reviewed.
Changing email or phone
- Require step-up.
- Verify the new address before it becomes active.
- Notify the old address with a one-click "this was not me" link that freezes the account.
- Keep the old address as a recovery contact for a cool-down period.
Deletion
- Require step-up, show what will be deleted, and confirm by email.
- Revoke sessions and tokens immediately; soft delete; hard delete on a published schedule that meets your privacy obligations (Chapter 16).
- Delete or anonymize personal data in logs and backups according to a written retention policy. Keep security audit records only as long as the law and your policy allow.
- Release identifiers for reuse only after the hard delete, and consider never reusing usernames.
Warning
Common mistakes
- Reset links that do not sign out existing sessions.
- Password reset that silently bypasses MFA.
- Recovery that a support agent can complete on a phone call.
- Email change that takes effect before the new address is verified.
Key takeaways
- Most account takeovers happen in signup, reset, recovery, and contact changes, not at the login form.
- Verification tokens are random, hashed, short lived, single use, and bound to one purpose.
- A reset must sign out every session and must never bypass MFA.
- For lost-everything recovery, use a waiting period with notifications, and keep human support last.