Recovery

24.0 What this chapter gives you#

1. You will be able to explain to somebody with no technical background why the strongest login in the world can be worth nothing, and why the thing that makes it worth nothing is the form marked “forgot your password”.
2. You will be able to do the arithmetic of the weakest link on a real account, calculate the combined chance that somebody gets in through any door at all, and show why adding a stronger front door barely moves that number.
3. You will be able to state exactly what NIST SP 800-63B revision 4 says about knowledge-based questions, quote the sentence, and give the measured figures from Google that killed them.
4. You will be able to specify a password reset token properly: how many random bits, how long it lives, how it is stored, how it is compared, when it is destroyed, and which four side channels leak it.
5. You will be able to design a recovery code scheme end to end, including how many bits, which alphabet, how it is displayed, how it is stored, and why it is hashed the same way a password is.
6. You will be able to explain why a deliberate waiting period is a security control rather than a nuisance, name three real products that use one, and say precisely what the delay buys and what it costs.
7. You will be able to describe how a helpdesk is defeated, walk through four published incidents with dates and figures, and list the controls that actually work against the attack rather than the ones that only look like they do.
8. You will be able to explain how account recovery works when the authenticator is a passkey, name the specific flags that tell a verifier whether the credential is synced, and identify the one account whose recovery now governs everything.
9. You will be able to describe what happens at the end of an account’s life - deletion, dormancy, recycled identifiers and inheritance - and name the specific rules and judgments that govern it as of August 2026.
10. You will be able to write a complete recovery flow with the threat model written next to each step, and defend every choice in it to somebody who wants to know why it is not simpler.

There is a house with a very good front door. The lock cannot be picked. The key cannot be copied. It opens for one person and refuses everybody else, including people who look exactly like that person and know everything about them. It is the best lock anybody has ever made.

Round the back there is a window with a broken catch.

That is the whole of this chapter, and it is the most useful sentence in this book. Every serious effort in authentication over the last fifty years has gone into the front door: better passwords, then codes that change, then keys that cannot be phished. Comparatively little effort has gone into what happens when the person who owns the house arrives without the key, and it is that path - the account recovery path - that decides how safe the house actually is. An attacker is not obliged to attack the thing you are proud of. They will attack whatever admits them, and they will find it faster than you will.

The chapter before this one, “Passkeys and WebAuthn”, describes the strongest widely deployed login we have: a key pair held by a device, where nothing secret is ever typed or transmitted, so a fake website has nothing to steal. That chapter earns its optimism. This chapter is the bill. A passkey lives on a device, and devices are lost, broken, stolen and replaced, and the moment you build the path that gets a person back in after that happens, you have built a second way into the account, and the account is now worth exactly the weaker of the two. The chapter after this one, “Why You Cannot Trust a Key You Were Handed”, takes up a different unfinished problem: how anybody knows whose key a key is in the first place.

We will do this in the usual order. First the idea in plain words, with a house, a locksmith and a note on the fridge, and one piece of arithmetic that a reader can check on paper. Then the places where that picture quietly lies. Then the real thing: token entropy, expiry windows, hashing, throttling limits, published breach figures, specification section numbers, and at the end a complete recovery flow with the threat model written beside every step. By the end you should be unable to look at a “forgot your password” link again without wanting to know what is behind it.

The plain version#

The house with the very good lock#

Priya has a flat, and on the front door is the best lock money can buy. It is not a lock that opens for a spoken word or a written number. It opens only for one physical key, and that key is in Priya’s pocket. Nobody can guess it, nobody can overhear it, and nobody can talk their way past it. If the front door were the only way in, the flat would be as safe as anything gets.

Now Priya drops the key down a drain.

She is standing outside her own flat. She is unquestionably the owner. She pays the rent, her clothes are inside, her cat is complaining through the letterbox. And the lock, which is very good, refuses her, because a very good lock refuses everybody who does not have the key, and that is the entire point of it.

So there has to be another way in. Not because anybody wants one, but because people lose keys. Every building that has ever existed has a second way in for exactly this reason, and the second way is never as good as the first, because the second way has to work for somebody who has nothing.

That is the shape of the problem. A way in for somebody with nothing is, by construction, a way in for anybody who has nothing, unless we can find something Priya has that a stranger does not. The whole of this chapter is a search for that something, and an honest accounting of how well each candidate holds up.

The locksmith who asks about the kitchen#

The first idea people had is the oldest and the worst.

The building keeps a locksmith. When somebody turns up saying they live at number 14 and have lost their key, the locksmith asks them questions about the flat. What colour are the kitchen tiles? What is the name of the cat? Where did you go on holiday the year you moved in? If the answers match what is written in the building’s book, the locksmith opens the door.

This feels reasonable. It is how a person would check another person. And it is broken in four separate ways at once, all of which are obvious the moment they are said out loud.

The first is that the answers are not secret. The cat’s name is on the collar. The holiday is in a photograph anyone can see. The kitchen tiles were in the estate agent’s listing. Priya never chose these facts to be secrets; they became secrets only because the locksmith decided to treat them as secrets, and deciding does not make it so.

The second is that the answers are shared. If Priya gives the cat’s name to this building and also to her bank and also to her email provider, then anybody who learns it at one place walks into all three. A secret you reuse in five places is not five secrets.

The third is that Priya forgets. Not the cat’s name - she forgets what she wrote down. Was it “Mishti” or “mishti” or “Mishti the cat”? Was her favourite food “pizza” or “Margherita pizza”? Three years have gone by. She is at the door, she is the owner, and she cannot get in, which is precisely the situation the locksmith exists to fix.

The fourth is the trap. Priya, being sensible, sees that the cat’s name is public and decides to give a false answer to make it harder to guess. Now the answer is a secret in earnest. It is also something she has no way of remembering, because it is not a fact about her life, it is an invented string she typed once. She has made the door safer against a stranger and impassable for herself in one action.

Later in the chapter we will look at the measurements that were actually taken on this, by people with access to hundreds of millions of real answers, and the numbers are worse than the argument.

The note on the fridge#

The second idea is much better and is almost never used properly.

When Priya moves in, the building gives her a card with ten numbers printed on it. It says: keep this somewhere safe and not in your handbag. If you ever lose your key, bring one of these numbers to the locksmith and he will let you in without any questions at all. Each number works once. When one is used, it is crossed off forever.

This works because it is honest about what it is doing. The building is not pretending to recognize Priya. It is giving her a second thing to hold, and asking her to hold it somewhere different from the first thing. The card in the drawer is not a question about her life that a stranger could research. It is a physical object, and a stranger has to steal it.

Two rules make or break this, and both get broken constantly.

The first rule is that the numbers must be long enough that guessing is hopeless. If the card says “one to ten”, a burglar walks up and says “seven”. If each number is twenty digits long, drawn at random, there are more possibilities than there are grains of sand on a beach and guessing is not a strategy.

The second rule is that the building must not keep a readable list of the numbers. If the building’s office keeps a book with everybody’s ten numbers written in it, then the book is now a master key to the whole building, and the person who steals the book owns every flat. The building should keep the numbers in a scrambled form that lets it check an answer without being able to read the answers - the same treatment a well-run system gives passwords, described in the chapter “Storing a Password”.

The neighbour who vouches#

The third idea uses other people.

Priya names three neighbours in advance. If she ever loses her key, the locksmith will not talk to her at all. He will send a short code to each of the three neighbours, and Priya must collect at least two of them and bring them back. The neighbours are not being asked to be careful; they are being asked to be a channel that runs through the physical world and through people who know Priya’s face.

This is genuinely good, and it fails in one specific way. The attacker does not attack the locksmith. The attacker rings Mrs Fernandes on the second floor and says, in a distressed voice, that she is Priya’s sister, Priya is locked out and in tears, and could she please read out the code that just came through. Mrs Fernandes is a kind woman with no training and no way to check. The strength of the scheme now rests entirely on how good a stranger is at sounding sincere on the telephone.

The locksmith who makes you wait#

The fourth idea does not add any new secret at all. It adds time.

The building changes one rule. The locksmith will still let somebody in without a key, and the test is no harder than before. But he will not do it today. He takes the request, and then for the next seven days he posts a notice on the flat door, sends a letter to the postal address, telephones the number on file, and tells the concierge. On the eighth day, if nobody has objected, he opens the door.

Think about what this does to the burglar. The burglar’s whole plan depended on being quick and quiet. He wanted to be inside and out before anybody noticed. Now the building has turned a silent theft into a seven-day public announcement addressed to the one person who will care. He can still start the process, but he cannot finish it without Priya having a week to say no.

And think about what it does to Priya. It is a serious inconvenience. If she has locked herself out on a Friday evening, seven days is a week in a hotel. This is the trade that runs through the whole subject: the only things that reliably stop a determined attacker also inconvenience the honest owner, and the honest owner is far more common. A design that pretends otherwise is selling something.

The man in the office who can open any door#

The fifth arrangement is the one every real building has, and the one nobody designs deliberately.

Somewhere in the building there is an office, and in that office there is a person with a master key and instructions to be helpful. The instructions say to verify the caller first. In practice the instructions are three lines long, the person handles ninety calls a day, is measured on how quickly the calls end, and is talking to somebody who is upset and in a hurry and possibly shouting.

An attacker who is polite, plausible, and knows two facts about Priya from the internet does not have to defeat the lock. He has to defeat a tired human being who has been told that his job is to solve problems. He rings up and says he is locked out. The person in the office asks a question. He answers it. The person in the office opens the door.

We will look at four real cases of exactly this later in the chapter, including one where a company’s own court filing quotes the transcript of the moment it happened.

The arithmetic, done on paper#

Here is the piece of arithmetic that makes this chapter worth reading, and it is simple enough to check by hand.

Priya’s flat has five ways in: the excellent lock, the card of numbers, the locksmith with his questions, the neighbours, and the office with the master key. Suppose for the sake of argument that over the course of a year, a determined attacker has these chances against each one. The numbers below are illustrative, chosen so that the arithmetic is easy to follow; they are not measurements of anything.

The attacker only has to succeed once, at any one of them. So the right way to combine these is to work out the chance that he fails at every single one, and subtract that from certainty.

He fails at the lock with probability 0.9999. He fails at the card with probability 0.99. At the neighbours, 0.98. At the office, 0.95. At the questions, 0.80. Multiply those together:

0.9999 x 0.99 = 0.9899 0.9899 x 0.98 = 0.9701 0.9701 x 0.95 = 0.9216 0.9216 x 0.80 = 0.7373

So he fails everywhere with probability 0.7373, which means he gets in with probability 0.2627. Call it 26 per cent.

Now look at what happened. The front door contributed one part in ten thousand. The flat as a whole is at one chance in four. The lock that everybody is proud of is responsible for 0.01 per cent of the risk, and the questions about the cat are responsible for most of the other twenty-six.

Do it again with the questions abolished:

0.9999 x 0.99 x 0.98 x 0.95 = 0.9216, so the chance of a break-in is 7.8 per cent.

And again with the office also removed from the picture, so that the only ways in are the lock, the card and the neighbours:

0.9999 x 0.99 x 0.98 = 0.9701, so the chance is 3.0 per cent.

Removing one bad path took the risk from 26 per cent to 7.8. Removing a second took it to 3.0. Upgrading the front door lock from one in ten thousand to one in ten million would have taken 26.27 per cent down to 26.26 per cent, which is to say it would have done nothing at all.

That is the thesis of this chapter in numbers. The strength of an account is not the strength of its login. It is the strength of the weakest path that leads inside, and account recovery is almost always that path.

Where the plain version stops being true#

The spare key is not a backup, it is a second front door#

The plain version talked about the card of numbers as a safety net, something held in reserve for a bad day. That framing is comfortable and it is wrong.

The honest version: a recovery method is not a backup, it is a second authenticator with full powers, live twenty-four hours a day, and it should be designed and reviewed exactly as if it were the primary login, because to an attacker it is the primary login. The word “backup” makes people apply a lower standard to it - fewer bits, weaker storage, no rate limit, no notification - and the lower standard is the whole vulnerability. If you would not accept a login method with those properties, you must not accept a recovery method with them.

“Only you know your mother’s maiden name” was never true#

The plain version said that questions about your life fail because the answers are guessable. That understates it in one direction and overstates it in another.

The honest version: the failure is not only that answers are guessable, it is that the answers were never secrets in the first place - most of them are attributes recorded in public registers, in the records of other companies, and in the person’s own published writing, and treating a public attribute as a secret is a category error rather than a weak choice of secret. At the same time, some questions genuinely are hard for a stranger. The problem is that the questions hardest for a stranger are also the ones the owner cannot recall three years later, and the measured trade-off between the two is so poor that no point on the curve is worth using. The correct conclusion is not “choose better questions”. It is that the whole family of methods is unsound.

Email is not a channel, it is the master key#

In the plain version the note in the postbox was one option among several. In real systems it is not one option among several. It is the foundation under most of the others.

The honest version: for the great majority of consumer accounts, control of the email address is control of the account, so the security of a hundred accounts collapses to the security of one mailbox, and the security of that mailbox collapses to its own recovery path. This is not a design anybody chose. It grew, because email was the only address every service already had. It has one useful consequence and one dangerous one. The useful consequence is that hardening a single mailbox hardens everything downstream of it. The dangerous one is that a person who has done everything right on ninety-nine accounts and left the hundredth - the mailbox - on a weak recovery path has done nothing at all.

A code that arrives on your phone is not proof that you hold the phone#

The plain version treated sending a number to Priya as if it reached Priya.

The honest version: a text message is delivered to whoever currently controls the telephone number, and the telephone number is controlled by a mobile operator’s customer service process, which is a helpdesk with exactly the weaknesses described later in this chapter. Transferring somebody’s number to a new card is a support transaction, not a cryptographic operation. The chapter “The Second Factor That Is Not” deals with that attack properly; here the only point that matters is that a phone number is a recovery path whose strength is set by a third party you have no contract with and cannot audit.

There is a second, quieter failure. Telephone numbers are recycled. Kevin Lee and Arvind Narayanan of Princeton sampled 259 numbers that United States carriers were offering to new subscribers and reported in 2021 that 171 of them - 66 per cent - were still tied to accounts at popular websites belonging to the previous owner. A person who gives up a number has not given up the recovery paths attached to it.

Delay protects you only if the alarm reaches somebody#

The plain version made the seven-day wait sound self-evidently good.

The honest version: a waiting period is not a control by itself, it is a control only in combination with a notification that arrives, is understood, and can be acted on, and if the attacker already controls the address the notification goes to, the delay simply tells them how long to wait. This is why the notification address and the recovery address must not be the same thing, and why a serious design sends the alarm to every address it has rather than to the one being used for the recovery.

The helpdesk is not a fallback, it is an authenticator with a human verifier#

The plain version described the office with the master key as a last resort outside the system.

The honest version: a support agent who can reset a credential is a verifier, the questions they ask are an authentication protocol, and the fact that the protocol is executed by a person rather than a program does not exempt it from analysis - it makes the analysis harder, because the protocol changes with the mood of the person running it. Every property we demand of a machine verifier applies: what evidence is accepted, how many attempts are allowed, whether the evidence can be replayed, whether it can be obtained by asking somebody else. A helpdesk process that has never been written down as a protocol has never been reviewed as one.

“Just delete the account” is not the end#

The plain version stopped when Priya got back in. Accounts do not stop there.

The honest version: deletion, dormancy and death are part of the recovery surface, not separate from it, because a deleted account can leave behind an identifier that somebody else is later given, a dormant account is an unwatched account with a live recovery path, and a dead person’s account is one that must be opened for somebody who is definitionally not the owner. Each of those is a way in, and the last of them is a way in that the law, rather than the engineer, gets to specify.

The technical version#

The weakest link, stated exactly#

Model a subscriber account as a set of admission paths. Path i is any sequence of steps that ends with the attacker holding a valid session or a bound authenticator. Let p sub i be the probability that an attacker of a stated capability succeeds on path i within a stated period.

If the paths are independent, the probability of at least one success is:

P(compromise) = 1 - PRODUCT over i of (1 - p_i)

Two consequences follow immediately and neither is intuitive.

The first is that the total is dominated by the largest p sub i. In the worked example above, the questions at 0.20 contributed 18.5 percentage points of the 26.3, and the front door at 0.0001 contributed one hundredth of one point. Improving a small p sub i cannot help. Only removing or shrinking the large ones can.

The second is that adding a path can only increase P, never decrease it. This is worth stating because it contradicts the way recovery options are usually discussed. Offering the subscriber “one more way to get back in” is spoken of as a service improvement. Arithmetically it is a strict increase in exposure, paid for in reduced lockout. That may be the right trade. It is never a free one.

NIST SP 800-63B revision 4, published on 31 July 2025 and superseding the March 2020 edition of SP 800-63B, encodes this directly. Its section 4.2 on account recovery does not permit a single weak path to stand alone. To recover a subscriber account that can authenticate at authentication assurance level 2, the credential service provider “SHALL require the subscriber to complete one of the following”: two recovery codes obtained by different methods from the set of saved codes, issued codes and recovery contacts; or one recovery code from that set plus authentication with a single-factor authenticator already bound to the account; or repeated identity proofing where the account was proofed in the first place.

Read that as arithmetic rather than as policy. It is a rule that forbids any single p sub i from being the whole of the recovery path. Two independent paths at 0.05 each combine to a joint requirement of 0.0025, which is the point.

The middle row is what section 4.2 requires. The bottom row is what most consumer systems ship, and the difference between 0.0025 and 0.0975 is a factor of thirty-nine.

Knowledge-based questions, and the sentence that abolished them#

The prohibition is explicit and it is worth having the exact words. NIST SP 800-63B revision 4, section 3.1.1.2, “Password Verifiers”, states:

“Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., ‘What was the name of your first pet?’) or security questions when choosing passwords.”

The 2017 edition, SP 800-63B revision 3, carried the same instruction in its section 5.1.1.2 in slightly different words: verifiers “SHALL NOT prompt subscribers to use specific types of information (e.g., ‘What was the name of your first pet?’) when choosing memorized secrets.” The requirement is nine years old as of August 2026 and is still routinely ignored.

The measurements that justify it come from a single paper that had access to data nobody outside a large provider can obtain. Joseph Bonneau, Elie Bursztein, Ilan Caron, Rob Jackson and Mike Williamson published “Secrets, Lies, and Account Recovery: Lessons from the Use of Personal Knowledge Questions at Google” at the WWW 2015 conference in Florence in May 2015. They analysed hundreds of millions of secret answers and millions of account recovery claims, including a random sample of 11 million recovery claims from 2013, with over a million answers behind each question studied.

Two families of numbers matter. The first is how well an attacker does with a small number of guesses at the single most common answer.

Nearly one English-speaking user in five could be impersonated by an attacker who typed “pizza” once. That is not a weak secret; it is not a secret.

The second family is how well the legitimate owner does. Here the paper compared secret questions with the other recovery methods on the same population.

The paper’s own summary is that “SMS and email-based account recovery have a significantly higher chance of success: 81% for SMS vs 75% for Email vs 61% (US/English) down to 44% (France/French) for secret questions”. A method that admits a stranger one time in five and refuses the owner two times in five is not on any sensible trade-off curve; it is dominated on both axes at once.

The paper also measured the trap described in the plain version. Of 1,500 survey respondents, 37 per cent who admitted giving false answers said they did so to make the answers harder to guess, and 15 per cent to make them easier to remember. And 62.8 per cent had never considered that the question could be used against them. Falsifying the answer moves the question from the guessable column to the unmemorable column without ever passing through a column where it is useful.

There is a residual and legitimate use that should not be confused with the abolished one. Asking a caller to confirm a fact already held in the record - the last four digits of an account number, the value of the most recent transaction - as one weak signal among several in a fraud model is a different activity from accepting a self-chosen answer as a credential. The first is corroboration. The second is authentication. Only the second is forbidden.

Reset tokens: entropy, expiry, single use#

A password reset token is a bearer credential. Anyone holding it is treated as the account owner, and it therefore needs the treatment given to a session cookie or an API key, not the treatment given to a form field.

Randomness first. SP 800-63B revision 4, section 3.2.12, “Random Values”, requires that random values referencing that section “SHALL be generated by an approved random bit generator that provides at least the minimum security strength specified in the latest revision of SP 800-131A (i.e., 112 bits as of the date of this publication).” In practice that means a cryptographically secure generator - the operating system’s, not the language’s default - and a token of at least 128 bits. A 128-bit token rendered in base64url is 22 characters. A 160-bit token is 27.

Length matters less than the source. A 256-bit token from a predictable generator is worth nothing; the vulnerability lives in the generator, never in the length. Systems have shipped reset tokens derived from the current time in seconds, from the user identifier, and from a counter, and each of those is a token an attacker can produce without ever seeing one.

Lifetime next. SP 800-63B revision 4, section 4.2.1.2, sets explicit ceilings for issued recovery codes, which is the specification’s name for a code sent to an address of record. The code “SHALL include at least six decimal digits (or equivalent) from an approved random bit generator”, and it “SHALL be valid for at most”:

Those numbers are a standard, not a convention, and the reasoning behind the spread is the delivery latency of each channel rather than any property of the code. A code sent by post is not weaker; it simply takes longer to arrive.

Six decimal digits is one million possibilities, which is about 19.93 bits. On its own that is trivially brute-forced, which is why the specification pairs it with a throttling requirement. SP 800-63B revision 4, section 3.2.2, “Rate Limiting (Throttling)”, requires the verifier to “limit consecutive failed authentication attempts using a specific authenticator on a single subscriber account to no more than 100 by disabling that authenticator”, and notes that “the limit of 100 was chosen to balance the likelihood of a correct guess (e.g., 100 attempts against a six-digit decimal OTP authenticator output) versus the potential need for account recovery when the limit is exceeded.”

Carry that through with real numbers. One hundred guesses against one million possibilities is a success probability of 100 divided by 1,000,000, which is 0.0001, or one in ten thousand. That is the actual security of a six-digit emailed code, and it is entirely a property of the throttle. Remove the throttle and the same code falls in seconds. This is the single most common defect in reset code implementations: the code is specified correctly and the counter is not implemented, or is implemented per session rather than per account, or resets when the attacker requests a new code.

Single use is the third property, and it is not one rule but four. The token must be invalidated when it is used. It must be invalidated when a new one is issued for the same account, so that requesting ten resets does not create ten live keys. It must be invalidated when the password actually changes by any other route. And the successful use of a reset must invalidate every existing session for the account, because otherwise an attacker who was already inside stays inside after the owner locks the door behind them.

Storage is the fourth. A table of live reset tokens is a table of live credentials. It should hold a hash of the token, not the token, so that read access to the database is not read access to every account currently in the middle of a reset. Because a 128-bit random token has full entropy, a fast approved one-way function is sufficient here; the slow key derivation functions described in the chapter “Storing a Password” exist to compensate for the low entropy of human-chosen secrets and are not needed for a value drawn from a generator. Compare the stored hash with a constant-time comparison, because a comparison that returns early on the first differing byte leaks the token one byte at a time to an attacker who can measure the response.

Side channels are the fifth, and this is where correct implementations still leak.

GET /reset?token=vT2v9y3iKzp0Fh7Rr4dJcQ HTTP/1.1
Host: accounts.example.com
Referer: https://accounts.example.com/reset?token=...

A token in a URL query string is written into the web server’s access log, into any intermediate proxy’s log, into the browser’s history, into the browser’s synced history on every other device the person owns, and - unless a referrer policy forbids it - into the Referer header sent to every third-party asset the reset page loads. If the reset page loads an analytics script or a font from another origin, the token is handed to that origin. Putting the token in the fragment, or exchanging it immediately for a short-lived server-side state and redirecting, removes most of this. Setting a strict referrer policy removes the rest.

The sixth is account enumeration. A reset form that says “no account with that address” for unknown addresses and “check your email” for known ones is a free membership oracle for the whole service. The fix is a single response for both cases, and it must be a single response in timing as well as in text: if the known-address branch sends an email and the unknown-address branch returns immediately, the difference in response time says the same thing the message used to. Send the mail asynchronously, or add a matched delay.

A defensible reset flow therefore looks like this.

1. POST /reset {email}
   -> always 200, always the same body
2. if account exists:
     t  = 16 random bytes from the OS CSPRNG
     h  = SHA-256(t)
     store (account_id, h, expires_at = now + 24h,
            used = false)
     invalidate any earlier unused rows
     mail link containing t
3. GET  /reset/confirm  (token in fragment or POST body)
     h' = SHA-256(t')
     look up by h', constant-time compare
     reject if used or expired
4. POST new password
     set used = true
     revoke every session for account_id
     notify EVERY address on file, not just this one

Recovery codes: generation, display, storage#

Saved recovery codes are the strongest of the common recovery methods, because they are the only one that gives the subscriber a genuinely new secret rather than reusing an address that somebody else controls.

The specification is precise. SP 800-63B revision 4, section 4.2.1.1, says the recovery code “SHALL include at least 64 bits from an approved random bit generator”, that saved recovery codes “SHALL be stored in the subscriber account in hashed form using an approved one-way function”, that verification “SHALL be subject to the throttling requirements” of section 3.2.2, and that “following the use of a saved recovery code, the CSP SHALL invalidate that recovery code and SHALL issue a new saved recovery code to the subscriber.”

Sixty-four bits is the floor and it is a well-chosen one. Two to the power of sixty-four is about 1.8 x 10 to the power 19. Against a throttle of 100 attempts, the success probability is around 5 x 10 to the power minus 18, which is not a number anybody needs to improve.

How you render 64 bits changes what the human experience is like.

Base32 with the Crockford or RFC 4648 alphabet is the usual choice for anything a person will copy off paper, because it removes the character pairs that get misread. Grouping matters too: five characters, a hyphen, five characters is read and typed far more reliably than ten characters in a row, and the hyphen is not part of the secret.

GitHub’s implementation is a reasonable public reference point. As of August 2026 its documentation states that enabling two-factor authentication produces a set of 16 recovery codes, that “once you use a recovery code to regain access to your account, it cannot be reused”, and that “if you’ve used all 16 recovery codes, you can generate another list of codes. Generating a new set of recovery codes will invalidate any codes you previously generated.” Note the last clause: regeneration is not additive. That is the correct behaviour, and it is also the behaviour that surprises users who assume they now have thirty-two codes.

Display-once is the rule that separates a recovery code scheme from a second password. The codes are shown at the moment of generation and never again. If they can be re-displayed inside an authenticated session, then an attacker who has obtained a session by any means - a stolen cookie, an unlocked laptop, a shoulder-surfed password - can walk to the settings page and mint themselves permanent access that survives every subsequent password change. Display-once is inconvenient and it is not negotiable. If codes must be viewable again, they must be regenerated rather than revealed, and the regeneration must invalidate the old set and must send a notification.

Generation, in full, with real values:

import os, base64, hashlib

def make_codes(n=10, nbytes=10):
    # 10 bytes = 80 bits, comfortably over the
    # 64-bit floor in SP 800-63B-4 sec 4.2.1.1
    out = []
    for _ in range(n):
        raw = os.urandom(nbytes)
        b32 = base64.b32encode(raw).decode()
        b32 = b32.rstrip("=")            # 16 chars
        out.append(b32[:5] + "-" + b32[5:10])
    return out

def store(code):
    # full-entropy secret: a fast approved one-way
    # function is sufficient, unlike a password
    return hashlib.sha256(code.encode()).hexdigest()

Two details in that fragment are deliberate. The bytes come from os.urandom, which reads the operating system generator, not from the language’s ordinary pseudo-random module, which is seeded predictably and is not for this. And the stored form is a hash, so that a database dump does not hand the attacker a working key to every account that has ever enabled the feature. The hash is fast rather than deliberately slow because the input has 80 bits of true randomness, so the offline guessing attack that slow hashing exists to frustrate is not available.

The one weakness of saved codes is human. The subscriber must put them somewhere, and the two commonest somewheres are a screenshot in the phone’s photo library, which is synced to the same cloud account the codes are meant to recover, and a note in the password manager that holds the password the codes are meant to replace. Both defeat the point entirely. Codes are only a second factor if they live somewhere the first factor does not.

Time as a control#

Delay is the most underrated mechanism in this chapter, because it costs nothing to build and it directly attacks the property every account takeover depends on: silence.

The mechanism is simple. When a recovery request arrives that cannot be satisfied by strong evidence, do not refuse it and do not grant it. Accept it, start a clock, and tell everybody. The account owner is given a window in which a single click cancels the whole thing. The attacker is given a window in which the only thing they can do is wait and hope the owner is not reading their messages.

Apple’s account recovery is the best-known consumer implementation. Its published support documentation states that “for security reasons, it might take several days or longer before you can use your account again after you start account recovery”, that the confirmation email “arrives within 72 hours”, and - the part that matters most - that “contacting Apple Support can’t help you shorten this time.” That last sentence is a security control expressed as a customer service policy. It removes the helpdesk from the equation entirely, which means the social engineer has nobody left to persuade.

Apple’s Stolen Device Protection, introduced in iOS 17.3 in January 2024, applies the same idea at a much shorter scale. When the device is away from familiar locations, a set of security-critical actions require biometric authentication, then a wait of approximately one hour, then biometric authentication again. The protected actions include changing the Apple Account password, signing out of the Apple Account, changing the device passcode, adding or removing a face or fingerprint, altering trusted devices, the recovery key or a recovery contact, and turning off Stolen Device Protection itself. The threat being addressed is specific and well documented: a thief who watched the owner type the passcode in a bar and then took the phone. The passcode alone used to be enough to take over the account within seconds. An hour is not a long time, but it is long enough for the owner to reach another device.

SP 800-63B revision 4 acknowledges the pattern in its own words in section 4.2: account recovery “is generally less convenient than authentication and - depending on the situation and recovery methods offered by the CSP - may involve extended waiting times.”

Three design rules make a delay real rather than decorative.

The first is that the notification must go everywhere, not to the address being used for the recovery. Section 4.6 of SP 800-63B revision 4 requires credential service providers to support at least two notification addresses per subscriber account, requires notifications to be sent to all of them except postal addresses, and adds a specific rule for this exact hole: “Account recovery notifications SHALL also be sent to a postal address if the only other notification address in the subscriber account is the address to which an issued recovery code was sent.”

The second is that cancellation must be strictly easier than completion. A single click in the notification, with no login required, should halt the recovery. The asymmetry is the point: the owner may be on a borrowed device with nothing.

The third is that the delay must not be shortenable by anybody, including the operator. If a sufficiently upset caller can get the wait waived, the wait is not a control, it is a queue.

The cost is real and it falls on the person least able to bear it. A fourteen-day recovery hold on a mail account is an annoyance for somebody with a laptop and a spare phone. It is a fortnight without access to medical letters, tax correspondence and identity documents for somebody whose only device has just been stolen. This book returns to that asymmetry repeatedly: a wrongly admitted attacker produces a number in a fraud report, and a wrongly delayed owner produces silence. Choosing the delay window is choosing how much of that silence you are willing to cause, and it deserves to be an explicit decision with a named owner rather than a default.

Recovery contacts and delegated trust#

Using other people as a recovery mechanism has a respectable academic origin. John Brainard, Ari Juels, Ronald Rivest, Michael Szydlo and Moti Yung proposed it as “Fourth-Factor Authentication: Somebody You Know” at the ACM Conference on Computer and Communications Security in 2006, arguing that alongside something you know, something you have and something you are, there is a fourth category: somebody who can vouch for you. Stuart Schechter, Serge Egelman and Robert Reeder took the idea to a live user study, “It’s Not What You Know, But Who You Know: A Social Approach to Last-Resort Authentication”, published at the ACM CHI conference in 2009, and found both that it worked and that the trustees themselves were the attack surface.

Deployment followed. Facebook shipped Trusted Friends in October 2011, sending five codes to five nominated friends and requiring three of them, and replaced it with a redesigned Trusted Contacts in 2013. Apple offers account recovery contacts, who can generate a code that lets the owner reset an Apple Account. The pattern is now mainstream.

SP 800-63B revision 4, section 4.2.1.3, treats recovery contacts as a variant of issued recovery codes with two adjustments for the human relay. The validity period “MAY be extended by 24 hours (e.g., valid for no more than 24 hours and 10 minutes if sent via text messaging) to provide additional time for the recovery contact to communicate the recovery code to the subscriber”, and confirmation of a newly added recovery address may be extended by the same amount. The specification also requires that if recovery contacts are supported, the provider “SHALL provide methods for subscribers to view and manage recovery contacts”, and says providers “SHOULD send a reminder annually to subscribers to review their list of recovery contacts.”

That annual reminder is not administrative tidiness. A recovery contact is a standing grant of authority to a named human being, and human relationships change. A list of trusted contacts chosen at the age of twenty-four and never revisited is a list of people who may now be strangers, ex-partners or dead. Recovery contacts decay in a way cryptographic keys do not.

The attack is the one from the plain version and it has no clean technical answer. The attacker contacts the trustee directly, in distress, claiming to be the account owner or somebody acting for them, and asks for the code. The trustee is untrained, unmonitored and motivated to help. Partial mitigations exist and each is imperfect: state plainly in the message itself that the code must be given only to the person named and only by voice, deliver the code through an application that shows the requesting account rather than through open SMS, require two contacts rather than one so that the attacker must succeed twice, and combine the contact with a delay so that the real owner is told what has happened even if the trustee is fooled.

Helpdesk-assisted recovery#

This is where the largest breaches of the last decade actually happened, and it is worth being unsentimental about why. A support agent is a verifier with the widest possible acceptance criteria, no rate limit, no audit of the decision at the time it is made, and an incentive structure that rewards resolving the call.

Four published cases, in order.

The first is the one that made the argument famous. On 6 August 2012 the journalist Mat Honan published “How Apple and Amazon Security Flaws Led to My Epic Hacking” in Wired. The attackers wanted his three-character Twitter handle. They telephoned Amazon and added a new credit card to his account using only his name, email address and billing address. They called back, used the new card number as proof of identity, and added a new email address. A password reset to that address let them into the Amazon account, where the last four digits of his real cards were displayed. They then telephoned AppleCare, where a billing address and the last four digits of a card on file were sufficient to obtain a temporary password. From the Apple account they reached his mail, then his Google account, then Twitter, and they remotely erased his iPhone, iPad and MacBook. He lost photographs of his daughter’s first year. His summary of it - that “a billing address and the last four digits of a credit card number are the only two pieces of information anyone needs” - remains the shortest available description of what is wrong with treating data as identity.

Note the structure, because it recurs. No system was hacked. Each company’s process was individually defensible. The exploit was that one company’s non-secret output was another company’s authentication input, and no one had drawn the diagram that showed it.

The second is the largest social media compromise on record. On 15 July 2020, between 20:00 and 22:00 UTC, 130 Twitter accounts were taken over and used for a bitcoin scam. The New York State Department of Financial Services investigated and published its report in October 2020. Its account of the entry is one sentence long: “The Twitter Hack started on the afternoon of July 14, 2020, when one or more Hackers called several Twitter employees and claimed to be calling from the Help Desk in Twitter’s IT department. The Hackers claimed they were responding to a reported problem the employee was having with Twitter’s Virtual Private Network.” Of the 130 targeted accounts, 45 had tweets sent from them, up to 36 had direct message inboxes accessed, and 7 had their full Twitter data downloaded. The bitcoin taken was approximately 118,000 United States dollars. The department also noted that Twitter had had no chief information security officer for the seven months preceding the incident.

The third is the case with a court record. In August 2023 the Clorox Company suffered a ransomware attack attributed to the group known as Scattered Spider. On 22 July 2025 Clorox filed suit against its outsourced IT provider Cognizant in Alameda County Superior Court in California, claiming 380 million United States dollars and pleading breach of contract, breach of good faith and fair dealing, gross negligence and intentional misrepresentation. The complaint quotes the service desk transcript. Asked for credentials by a caller with no login details, the agent replied: “Oh, ok. Ok. So let me provide the password to you ok?” The filing alleges that agents reset multi-factor authentication and changed the telephone numbers used for SMS authentication without asking for an employee identification number or manager verification, that the caller was never verified, and that no notification was sent to the impersonated employee or their manager. The attackers repeated the trick against an IT security employee’s account and obtained domain administrator privileges. Clorox has reported 49 million dollars in direct remediation costs and 380 million dollars in overall losses.

The fourth changes the threat model. On 14 May 2025 Coinbase filed a Form 8-K disclosing that criminals had bribed overseas customer support contractors to extract customer data, and stated that it had “preliminarily estimated expenses to be within the range of approximately $180 million to $400 million relating to remediation costs and voluntary customer reimbursements”. Here the agent was not deceived. The agent was the attacker. Every control aimed at helping the agent make a better decision is worthless against this, because the decision was made correctly from the agent’s point of view.

What actually works against this is a short list, and most of it is structural rather than procedural.

Remove the capability. The strongest control is that the agent physically cannot complete a credential reset. They can start one, which begins a delayed, notified flow that the subscriber must finish on their own device. This is what Apple’s refusal to shorten the waiting period amounts to in practice.

Make the evidence unaskable. Verify by calling back on the number of record rather than the number the caller is using; the attacker must then already control the number, which is a harder attack. Better still, push a prompt to a device already bound to the account.

Require two people. A reset that requires a second agent’s approval defeats the deceived-agent case entirely and raises the cost of the bribed-agent case from one person to two.

Notify unconditionally and out of band. Every one of the four incidents above would have been detected far earlier by a message to the account holder’s other addresses. In the Clorox filing the absence of that message is pleaded as a specific failure.

Throttle the agent, not the caller. Rate limits are usually applied to accounts. In helpdesk fraud the account changes every time and the agent does not. An agent who has performed fifteen credential resets today when the median is two is the signal.

Record everything and review a sample. The Clorox transcript exists because calls were recorded. Recording after the fact is evidence; sampling and reviewing it weekly is a control.

Recovery when the authenticator is a passkey#

A passkey, described properly in the chapter “Passkeys and WebAuthn”, is a key pair created for one website, where the private half stays in the authenticator and only a signature is ever sent. It is the first widely deployed authenticator that a phishing site cannot defeat. Its recovery story is genuinely different from a password’s, and it has one uncomfortable property that is not always stated plainly.

The first and best answer is multiplicity. Because a passkey is per-device, not per-person, the natural design is to bind several. A user with a passkey on a phone, a passkey on a laptop and a hardware security key in a drawer has no recovery problem at all when one of the three is lost; they authenticate with a survivor and enrol a replacement. SP 800-63B revision 4, section 4.1.2.1, is explicit about preferring this: “To minimize the need for account recovery, CSPs and verifiers SHOULD encourage subscribers to maintain at least two separate means of authentication.” Its Appendix B on syncable authenticators lists “bind multiple authenticators at AAL2 and above to support recovery” as a mitigation in its own right.

This works and almost nobody does it, because the enrolment moment is exactly when the user wants to be finished. The design answer is to make the second credential part of the first flow rather than an item in a settings page: after the first passkey is created, the next screen should not be the home page.

The second answer is platform synchronization, and this is where the interesting trade sits. A synced passkey is copied, in encrypted form, into a cloud keychain, so a new phone gets the credential automatically. Losing the device stops being a recovery event at all. Apple’s iCloud Keychain does this with escrow records protected by hardware security modules; Apple’s platform security documentation states that “the escrow service allows only 10 attempts to authenticate and retrieve an escrow record” and that “after the 10th failed attempt, the HSM cluster destroys the escrow record and the keychain is lost forever.” The ten-attempt cap is what makes a six-digit device passcode adequate to protect the escrow: 10 guesses against 1,000,000 is one chance in a hundred thousand.

The cost is a change of subject. Once passkeys sync, the security of every account that uses them is bounded by the security of the platform account, and the security of the platform account is bounded by its own recovery flow. NIST names this exactly in Appendix B, in the row headed “Unauthorized access to sync fabric and recovery”: “Synced keys are accessible via cloud-based account recovery processes, which represent a potential weakness to the authenticators.” Its mitigations include requiring AAL2 authentication to add any new authenticator to the sync fabric, notifying the user of recovery activity, and using “a user-controlled secret (i.e., something not known to the sync fabric provider) to encrypt and recover keys.”

Appendix B also sets baseline requirements on the sync fabric itself: cloned keys “SHALL only be stored in an encrypted form” at a minimum security strength of 112 bits, private key operations “SHALL” happen on the local device, and access to keys in the fabric “SHALL be protected by AAL2-equivalent MFA”. It notes bluntly that “syncing violates the non-exportability requirements of AAL3”, which is why a synced passkey cannot reach the highest assurance level however well it is implemented.

A relying party can see some of this. WebAuthn defines two flags in the authenticator data that bear directly on recovery planning.

NIST’s guidance on these two is careful and worth repeating. On Backup Eligible: “It is important to note that just because an authenticator can be synced does not mean that it has been synced.” On Backup State: verifiers may restrict on it, but “agencies SHOULD NOT condition acceptance based on this flag for public-facing applications due to user experience concerns.” The practical use of BE is not to refuse credentials. It is to know whether this particular user is one lost phone away from a recovery event, and to prompt them to add a second credential if they are.

The third answer is hardware backup, and it is the enterprise pattern: issue two security keys, register both, and require the second to be stored separately. It removes the sync fabric from the trust chain altogether at the cost of buying and tracking a second piece of hardware. For AAL3 it is not an option but a requirement, because the key must not be exportable.

The honest summary is that passkeys do not remove the recovery problem, they relocate it. For a device-bound credential the recovery problem is “what if the device is lost”. For a synced credential the recovery problem is “what happens when somebody recovers the platform account”, and that question is answered by a company you do not control, using methods that ultimately bottom out in an email address, a telephone number or a support agent. The recursion terminates somewhere, and the design work is knowing where.

The end of the lifecycle: deletion, dormancy, inheritance#

An account’s last day is a recovery problem wearing different clothes.

Deletion is a right in law in a growing number of places, and the mechanics of it are a security matter. Under the General Data Protection Regulation, article 17 gives a right to erasure. In India, the Digital Personal Data Protection Act 2023 gives a corresponding right, and the Digital Personal Data Protection Rules 2025, notified by the Ministry of Electronics and Information Technology on 13 November 2025, put timers on it. The Third Schedule, read with rule 8, requires certain large data fiduciaries - e-commerce entities and social media intermediaries with at least two crore registered users in India, and online gaming intermediaries with at least fifty lakh - to erase personal data three years after the data principal last approached them for the specified purpose or exercised their rights, or from the commencement of the rules, whichever is later, with at least 48 hours’ notice before the erasure takes effect.

Google’s inactive account policy, announced on 16 May 2023 with deletions beginning in December 2023, sets two years of non-use as the threshold and states that Google “reserves the right to delete an inactive Google Account and its activity and data if you are inactive across Google for at least two years.”

Deletion is not, however, the safe end state people assume, because of identifier recycling. When a mail address is released and later reassigned, every account that used it as a recovery address now has a recovery path pointing at a stranger. The same is true of telephone numbers, and there the measurement quoted earlier applies directly: of 259 recycled numbers sampled by Lee and Narayanan from United States carriers and reported in 2021, 171 were still tied to existing accounts belonging to the previous owner. The mitigation is a service-side one and it is cheap: do not treat an address as a recovery address if the address has been re-registered since it was verified, and re-verify recovery addresses periodically rather than once.

Dormancy is the middle state and it is the dangerous one. A dormant account is fully live, has all of its recovery paths intact, and has nobody watching the notifications. Every alarm the design depends on rings in an empty room. The controls are unglamorous: expire unused recovery methods, require periodic re-verification of recovery addresses, and treat a login to a long-dormant account as a high-risk event rather than a routine one.

Inheritance is the case where the correct answer is to admit somebody who is definitively not the account holder, and here the law leads and the engineering follows.

In the United States, the Uniform Law Commission promulgated the Uniform Fiduciary Access to Digital Assets Act in 2014 and, after opposition from service providers, a revised version - RUFADAA - in 2015, which most states have since enacted. Its structure is a three-tier priority: a provider’s own online tool for designating a successor takes precedence; failing that, the terms of a will or trust; failing that, the provider’s terms of service. Section 7 requires a record evidencing the user’s consent before a personal representative may obtain the contents of electronic communications, so silence means no disclosure.

The leading judgment on the point is Ajemian v. Yahoo!, Inc., decided by the Supreme Judicial Court of Massachusetts on 16 October 2017 and reported at 478 Mass. 169. The personal representatives of John Ajemian sought the contents of his email account. Yahoo argued that the Stored Communications Act of 1986 prohibited disclosure. The court held that the Act’s lawful consent exception allows a personal representative to give consent on the decedent’s behalf, so the Act did not bar Yahoo from disclosing the contents. The Supreme Court of the United States denied certiorari in 2018. The decision matters because it separates two things engineers routinely conflate: whether a provider is permitted to disclose, and whether it is required to.

The provider-side tools RUFADAA prioritizes are now common. Google’s Inactive Account Manager lets a user nominate trusted contacts and specify what they receive after a chosen period of inactivity. Apple’s Legacy Contact scheme issues the nominated person an access key; Apple’s documentation states that the legacy contact “must have both the access key and your death certificate to request access”, and that certain data is excluded, specifically “movies, music, books, or subscriptions you purchased with your Apple Account, and data stored in your iCloud Keychain.” That exclusion is not arbitrary. The keychain is where the passkeys are, so the inheritance mechanism deliberately stops short of handing over the credentials to everything else.

SP 800-63B revision 4 covers the terminal case in section 4.5, on invalidation: providers “SHALL promptly invalidate authenticators when a subscriber account ceases to exist (e.g., subscriber’s death, the discovery of a fraudulent subscriber), when requested by the subscriber, when the authenticator is compromised, or when the CSP determines that the subscriber no longer meets its eligibility requirements”, and adds the principle that governs the whole area: “The consequences of not invalidating a compromised authenticator are usually more significant than the denial-of-service potential of invalidating one in error.”

The full shape of the lifecycle, then, is this.

  enrol ---> active <---------------+
              |  ^                  |
              |  | recovery         | re-verify
              v  |                  |
          lost authenticator        |
              |                     |
     +--------+--------+            |
     |        |        |            |
   saved   issued   contact --------+
   code     code
              |
              v  (none succeed)
       repeat identity proofing
              |
              v
  active ---> dormant ---> deleted ---> identifier
              (no          (erasure     recycled
               alarms       timer)      -> new owner
               heard)                    inherits the
                                         recovery path
  active ---> deceased ---> legacy contact / fiduciary

A designed recovery flow, with the threat model beside each step#

Here is a complete flow for a consumer account holding real value - a mail account, a bank, an exchange - written so that each step names the attack it exists to stop. It targets the requirements of SP 800-63B revision 4 section 4.2 for an account at authentication assurance level 2.

Step 1. The subscriber requests recovery by entering an account identifier. The system responds identically whether or not the account exists, in body and in timing, and applies a per-address and per-network-block rate limit. Threat addressed: account enumeration, and the use of the recovery form as a membership oracle to confirm which addresses hold accounts.

Step 2. The system evaluates what the subscriber can still present. If any bound authenticator remains usable, this is not a recovery at all; it is the binding of a replacement authenticator under section 4.1.2.1, and it requires authentication at the account’s current assurance level. Threat addressed: the very common design error of routing every “I cannot log in” through the weakest path when a strong one is still available.

Step 3. If nothing remains, the subscriber chooses among the offered methods: a saved recovery code, an issued code to a verified address, or a recovery contact. Two must be completed, from different classes, or one plus a surviving single-factor authenticator. Threat addressed: single-path compromise. This is the arithmetic from the start of this section made into a rule.

Step 4. Issued codes carry at least six decimal digits from an approved generator and expire on the schedule in section 4.2.1.2 - ten minutes by text or voice, twenty-four hours by email, twenty-one or thirty days by post. Each is single use. Verification is throttled under section 3.2.2. Threat addressed: brute force of a short code, replay of an old code, and the standing validity of a code intercepted weeks earlier.

Step 5. Saved codes are compared against stored hashes in constant time; a used code is invalidated and a fresh one issued. Threat addressed: database disclosure yielding usable credentials, and timing leakage of the stored value.

Step 6. At the moment the request is accepted, and before anything changes, a notification goes to every address on file - not to the address used in the recovery. If the only other address on file is the one that received the issued code, a postal notification is also sent, as section 4.6 requires. Threat addressed: silent takeover, and the specific hole where the attacker’s own address is also the only notification address.

Step 7. A hold of a stated length begins. The notification contains a one-click cancellation that requires no login. Any successful authentication with a surviving authenticator during the hold cancels it. The hold cannot be shortened by support staff, by escalation, or by any internal role. Threat addressed: speed, which is the attacker’s only real advantage, and the social engineering of whoever has the power to waive the wait.

Step 8. If the hold expires without objection, the subscriber binds a new authenticator. The binding follows section 4.1.2. The system prompts immediately for a second authenticator and does not treat the flow as finished until either a second is bound or the subscriber has explicitly declined. Threat addressed: the account emerging from recovery in the same single-authenticator state that caused the recovery.

Step 9. Every existing session, refresh token, application password and API key is revoked. Any recovery addresses added within the hold window are removed. Threat addressed: an attacker who was already inside surviving the reset, and an attacker who used the recovery window to plant a fresh path for later.

Step 10. Post-conditions are notified again, to every address, with an explicit statement of what changed, and the account is flagged for elevated monitoring for a defined period. Threat addressed: the slow-burn takeover in which the attacker changes nothing visible for a fortnight.

If no combination in step 3 is available, the flow must terminate in one of exactly two places. Either the subscriber repeats identity proofing under section 4.2.1.4, or the account is not recoverable. The second outcome must be stated plainly to the subscriber in advance, at enrolment, in words. A system that quietly maintains an undocumented final path through a support agent has all of the risk of that path and none of the honesty.

What to measure#

A recovery system that is not measured is a recovery system nobody knows the shape of. Six numbers are worth having, and only two of them are usually collected.

The recovery success rate is the share of started recoveries that complete. The abandonment rate is the share that stop partway, and it is the closest available proxy for legitimate users being locked out, because a locked-out user does not file a report, they simply leave. Time to recovery, at the median and at the ninetieth percentile, tells you what the delay policy is actually costing. The disputed recovery rate - recoveries later repudiated by the account holder - is the only direct measurement of the attack succeeding. The agent-completed share tells you how much of your recovery volume is running through the path with the worst properties. And the second-authenticator adoption rate, measured after every recovery, tells you whether the same account will be back next year.

The asymmetry this book keeps returning to applies with full force here. A fraudulent recovery produces a complaint, a chargeback and a line in a report. A wrongful refusal produces nothing at all: the person tries three times, gives up, and is gone. Only one of those two failures is visible in the data, so a team that optimizes what it can see will drift, month by month, towards refusing more people, and will believe the whole time that it is getting better. Measuring abandonment is the correction.

24.98 Common wrong ideas#

Wrong: Account recovery is a support feature, so it belongs to the customer service team rather than the security team. Right: Account recovery is an authentication path with full account privileges, and it is usually the weakest one. NIST SP 800-63B revision 4 devotes section 4.2 to it as a normative requirement, specifying minimum entropy, maximum validity periods, storage in hashed form, throttling and mandatory notification. A recovery flow that has not been threat-modelled has not been designed; it has only been built, and the four incidents in this chapter all began there.

Wrong: Security questions are weak but harmless as an extra check alongside something stronger. Right: Adding a path can only increase the probability of compromise, never decrease it, because the attacker chooses which path to attack. Bonneau, Bursztein, Caron, Jackson and Williamson measured at Google in 2015 that a single guess of “pizza” answers the favourite-food question for 19.7 per cent of English-speaking users, while the same population’s own recall of their answers was 60.8 per cent. SP 800-63B revision 4 section 3.1.1.2 states that verifiers and credential service providers “SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) ... or security questions”.

Wrong: A six-digit code emailed to the user is too short to be safe. Right: Six decimal digits is one million possibilities, about 19.93 bits, and SP 800-63B revision 4 section 4.2.1.2 accepts exactly that as the minimum for an issued recovery code. Its safety comes entirely from the pairing with section 3.2.2, which caps consecutive failed attempts at 100 and thereby fixes the guessing probability at one in ten thousand, and from the validity ceilings of ten minutes by text and twenty-four hours by email. The defect to look for is never the digit count; it is a missing or resettable counter.

Wrong: Recovery codes can be stored in plain text because they are only a fallback and are rarely used. Right: They are permanent bearer credentials that bypass every other control, so a database disclosure hands the attacker every account that ever enabled them. SP 800-63B revision 4 section 4.2.1.1 requires that saved recovery codes “SHALL be stored in the subscriber account in hashed form using an approved one-way function”. Because the code carries at least 64 bits of true randomness, a fast approved hash is sufficient; the slow key derivation functions used for passwords exist to compensate for low entropy, which is not a problem these have.

Wrong: A password reset link sent by email is safe because email is private. Right: The reset link is a bearer credential in a URL, and a URL leaks into web server logs, proxy logs, browser history synced across every device the person owns, and the Referer header sent to every third-party asset the reset page loads unless a referrer policy forbids it. Beyond that, control of the mailbox is control of the account, which makes the mailbox’s own recovery path the real security of every service downstream of it.

Wrong: A waiting period before recovery is user-hostile friction with no security value. Right: Delay attacks the one property every account takeover depends on, which is silence, by converting a quiet theft into a notified race that the legitimate owner wins with a single click. Apple’s published account recovery documentation states that the wait “might take several days or longer” and that “contacting Apple Support can’t help you shorten this time”, which simultaneously imposes the delay and removes the helpdesk as a target. The cost is real and falls hardest on people with only one device, which is why the window is a decision that needs an owner rather than a default.

Wrong: A helpdesk cannot be a serious vulnerability because agents are trained to verify callers. Right: An agent is a verifier with unbounded acceptance criteria and no rate limit, and training is not a control that survives contact with a plausible caller and a call-handling target. The New York Department of Financial Services found that the July 2020 Twitter compromise of 130 accounts began with calls claiming to be “from the Help Desk in Twitter’s IT department” about a VPN problem. Clorox’s July 2025 complaint against Cognizant quotes an agent answering a request for credentials with “Oh, ok. Ok. So let me provide the password to you ok?” The controls that work are structural: remove the agent’s ability to complete a reset, call back on the number of record, require a second approver, and notify unconditionally.

Wrong: Passkeys solve the recovery problem, because there is no secret left to reset. Right: They relocate it. A device-bound passkey makes device loss into a recovery event, which is why SP 800-63B revision 4 section 4.1.2.1 says providers “SHOULD encourage subscribers to maintain at least two separate means of authentication”. A synced passkey removes device loss as an event and makes the platform account the single point of failure instead, which NIST’s Appendix B names directly: “Synced keys are accessible via cloud-based account recovery processes, which represent a potential weakness to the authenticators.”

Wrong: The Backup State flag in a WebAuthn assertion should be used to reject synced credentials from consumers. Right: Backup Eligible tells you the credential may be synced and Backup State tells you it has been, and NIST’s guidance is that agencies “SHOULD NOT condition acceptance based on this flag for public-facing applications due to user experience concerns”. Rejecting synced credentials in a consumer service pushes users back to SMS codes, which are weaker in every respect. The useful reading of the flags is diagnostic: a device-bound-only user is one lost device away from a recovery event and should be prompted to enrol a second credential.

Wrong: Once an account is deleted the recovery risk is over. Right: Deletion frees an identifier, and a freed identifier is often reassigned. Lee and Narayanan sampled 259 telephone numbers offered to new subscribers by United States carriers and reported in 2021 that 171 of them - 66 per cent - were still tied to the previous owner’s accounts at popular websites. The same applies to reassigned mail addresses. Recovery addresses need periodic re-verification rather than one verification at the point they were added, and an address that has been re-registered since verification must not be treated as a recovery path.

24.99 Chapter summary in 20 lines#

1. Every authentication system is only as strong as the path that bypasses it, and in nearly every real deployment that path is account recovery rather than the login itself.
2. If admission paths are independent, the chance of compromise is one minus the product of the individual failure probabilities, so the total is dominated by the worst path and adding a path can only make it worse.
3. In the worked example the excellent front door contributed one part in ten thousand while the security questions contributed most of a twenty-six per cent annual risk, and removing them alone took the total to 7.8 per cent.
4. NIST SP 800-63B revision 4, published on 31 July 2025 and superseding the March 2020 edition, states in section 3.1.1.2 that verifiers and credential service providers SHALL NOT prompt subscribers to use knowledge-based authentication or security questions.
5. Bonneau, Bursztein, Caron, Jackson and Williamson measured at Google in 2015 that one guess answers the English favourite-food question for 19.7 per cent of users, while owners recall their own answers only 60.8 per cent of the time in en_US and 44.2 per cent in fr_FR.
6. Their measured success rates for SMS and email reset codes, 80.9 and 74.6 per cent, beat every secret question in every language they studied, which is why the questions are dominated on both security and usability at once.
7. Falsifying a security question answer moves it from the guessable column to the unmemorable column, and 37 per cent of surveyed users who gave fake answers said they did it precisely to make guessing harder.
8. A password reset token is a bearer credential and needs at least 128 bits from an operating system cryptographic generator, a hashed representation in the database, a constant-time comparison, single use, and invalidation of every session on success.
9. SP 800-63B revision 4 section 4.2.1.2 caps issued recovery codes at ten minutes by text or voice, twenty-four hours by email, twenty-one days by post within the contiguous United States and thirty days beyond it.
10. Six decimal digits is about 19.93 bits, and its safety comes entirely from section 3.2.2’s cap of 100 consecutive failed attempts, which fixes the guessing probability at one in ten thousand.
11. Tokens placed in URL query strings leak into server logs, proxy logs, synced browser history and the Referer header sent to third-party assets, and a reset form that answers differently for known and unknown addresses is a membership oracle in both text and timing.
12. Saved recovery codes must carry at least 64 bits from an approved generator, be stored hashed, be throttled, be invalidated on use with a replacement issued, and be displayed exactly once so that a stolen session cannot mint permanent access.
13. Delay is a control because it converts a silent takeover into a notified race, and Apple’s published documentation both imposes a wait of several days and states that contacting support cannot shorten it, which removes the helpdesk as a target.
14. A delay only works if the notification reaches somebody, which is why SP 800-63B revision 4 section 4.6 requires at least two notification addresses and requires a postal notification when the only other address is the one that received the recovery code.
15. Recovery contacts date from the “Fourth-Factor Authentication: Somebody You Know” proposal at ACM CCS in 2006 and Facebook’s Trusted Friends of October 2011, and their weakness is that the attacker telephones the trustee rather than the service.
16. Helpdesk social engineering produced the 2012 Honan takeover, the 15 July 2020 compromise of 130 Twitter accounts described in the New York Department of Financial Services report, and the August 2023 Clorox breach whose July 2025 complaint quotes an agent offering the password unprompted.
17. The May 2025 Coinbase disclosure, estimating 180 to 400 million United States dollars, shows the variant no agent training can address, because the agents were bribed rather than deceived, which is what two-person approval exists for.
18. Passkey recovery is answered first by binding several credentials, second by platform sync whose escrow Apple protects with hardware modules that destroy the record after ten failed attempts, and third by a second hardware key held separately.
19. Synchronization does not remove the recovery problem, it moves it to the platform account, which NIST’s Appendix B names as “unauthorized access to sync fabric and recovery” and mitigates with AAL2 authentication to add authenticators, notification, and a user-controlled secret.
20. The lifecycle ends in deletion, dormancy or death, and each is a recovery surface: recycled identifiers inherit recovery paths, dormant accounts ring their alarms in empty rooms, and inheritance is governed by RUFADAA of 2015 and by Ajemian v. Yahoo!, Inc., decided by the Supreme Judicial Court of Massachusetts on 16 October 2017.

Chapter sources: NIST Special Publication 800-63B-4, “Digital Identity Guidelines: Authentication and Authenticator Management”, Temoshok, Fenton, Choong, Lefkovitz, Regenscheid, Galluzzo and Richer, published 31 July 2025 and superseding SP 800-63B of 2 March 2020, in particular section 3.1.1.2 on password verifiers and the prohibition on knowledge-based authentication, section 3.2.2 on rate limiting and the limit of 100 consecutive failed attempts, section 3.2.12 on random values and the 112-bit security strength drawn from SP 800-131A, section 4.1.2.1 on binding an additional authenticator, section 4.1.2.2 on binding across endpoints and the 40-bit and 112-bit binding codes valid for a maximum of 10 minutes, the whole of section 4.2 on account recovery including 4.2.1.1 on saved recovery codes and the 64-bit minimum, 4.2.1.2 on issued recovery codes and the 10-minute, 24-hour, 21-day and 30-day validity ceilings, 4.2.1.3 on recovery contacts and the 24-hour extension, 4.2.1.4 on repeated identity proofing and 4.2.2 on recovery requirements by assurance level, section 4.5 on invalidation, section 4.6 on account notifications and the two-address minimum, and Appendix B on syncable authenticators including the cloning requirements, the WebAuthn User Present, User Verified, Backup Eligible and Backup State flags, and Table 5 on threats and mitigations; NIST Special Publication 800-63B revision 3 of June 2017 with errata of March 2020, sections 5.1.1.2, 5.1.2.2 and 5.1.3.2, for the earlier wording of the same prohibitions and for the 20-bit, 64-bit and 112-bit look-up secret thresholds and the 10-minute out-of-band validity; Joseph Bonneau, Elie Bursztein, Ilan Caron, Rob Jackson and Mike Williamson, “Secrets, Lies, and Account Recovery: Lessons from the Use of Personal Knowledge Questions at Google”, Proceedings of the 24th International Conference on World Wide Web, Florence, 18 to 22 May 2015, for the single-guess and ten-guess success rates by question and language, the comparison of secret questions with SMS and email reset codes, the 11 million recovery claim sample from 2013 and the 1,500-respondent survey; John Brainard, Ari Juels, Ronald Rivest, Michael Szydlo and Moti Yung, “Fourth-Factor Authentication: Somebody You Know”, ACM Conference on Computer and Communications Security, 2006; Stuart Schechter, Serge Egelman and Robert Reeder, “It’s Not What You Know, But Who You Know: A Social Approach to Last-Resort Authentication”, ACM CHI, 2009; Kevin Lee and Arvind Narayanan, “Security and Privacy Risks of Number Recycling at Mobile Carriers in the United States”, Proceedings of the 2021 APWG Symposium on Electronic Crime Research, for the sample of 259 recycled numbers of which 171 were still tied to previous owners’ accounts; Mat Honan, “How Apple and Amazon Security Flaws Led to My Epic Hacking”, Wired, 6 August 2012; New York State Department of Financial Services, “Report on Investigation of Twitter’s July 15, 2020 Cybersecurity Incident and the Implications for Election Security”, October 2020, for the help desk vishing account and the counts of 130 targeted accounts, 45 with tweets sent, up to 36 with direct message inboxes accessed and 7 with Twitter data downloaded; the Clorox Company complaint against Cognizant Technology Solutions filed in Alameda County Superior Court, California, on 22 July 2025, claiming 380 million United States dollars and quoting the service desk transcripts, together with Clorox’s reported 49 million dollars of direct remediation cost arising from the breach of 11 August 2023; Coinbase Global, Inc., Form 8-K filed with the United States Securities and Exchange Commission on 14 May 2025, for the estimate of approximately 180 million to 400 million dollars; MGM Resorts International’s disclosure of an approximately 100 million dollar impact from its September 2023 incident; Apple’s platform security documentation on escrow security for iCloud Keychain, for the 10-attempt limit and the destruction of the escrow record, together with Apple’s support documentation on account recovery, recovery contacts, Legacy Contact and Stolen Device Protection introduced in iOS 17.3 in January 2024; GitHub’s documentation on configuring two-factor authentication recovery methods, for the set of 16 single-use recovery codes and the invalidation of prior sets on regeneration, as of August 2026; Google’s announcement of 16 May 2023 on updating inactive account policies, with deletions from December 2023 after two years of inactivity; W3C “Web Authentication: An API for accessing Public Key Credentials - Level 3” for the authenticator data flag definitions; Regulation (EU) 2016/679, article 17, on the right to erasure; the Digital Personal Data Protection Act, 2023 (India) and the Digital Personal Data Protection Rules, 2025, notified by the Ministry of Electronics and Information Technology on 13 November 2025, rule 8 and the Third Schedule, for the three-year inactivity erasure trigger and the 48-hour pre-erasure notice; the Uniform Fiduciary Access to Digital Assets Act of 2014 and the Revised Uniform Fiduciary Access to Digital Assets Act of 2015 of the Uniform Law Commission, section 7; and Ajemian v. Yahoo!, Inc., 478 Mass. 169, 84 N.E.3d 766, decided 16 October 2017, certiorari denied 2018, on the lawful consent exception to the Stored Communications Act of 1986.