Designing Customer Account Recovery in a 2FA World

Designing Customer Account Recovery in a 2FA World

Speakers: Kelley Robinson, Account Security, Twilio

Conference: LocoMocoSec

YouTube: https://www.youtube.com/watch?v=LDQT9aFbUzc

Overview

In "Designing Customer Account Recovery in a 2FA World," Kelley Robinson, an expert in account security at Twilio, delves into the critical and often overlooked aspects of implementing robust account recovery mechanisms for consumer-facing applications, particularly in an environment increasingly reliant on Two-Factor Authentication (2FA). Given the unprecedented shift towards online business in 2020, the need to fortify online authentication has become paramount. However, while 2FA significantly enhances security, it introduces a complex challenge: how do users regain access to their accounts when they lose an authentication factor, such as a phone, security key, or even forget a password?

Robinson meticulously distinguishes between consumer account recovery and enterprise solutions, highlighting that consumer applications, with their vast and diverse user bases, cannot rely on internal security hotlines or high-touch support models. Instead, they require scalable, secure, and user-friendly self-service or semi-automated recovery paths. The talk draws upon Twilio's extensive experience with user verification products and running Authy, their popular 2FA application, to share practical insights and actionable recommendations for developers and security professionals grappling with these challenges.

The core message of the talk is that account recovery should be viewed not as a mere fallback, but as an alternative authentication system in its own right. It carries inherent risks because it involves reproving an identity to an account that already holds value or sensitive data, making it a prime target for attackers. Robinson emphasizes that poorly designed recovery processes can negate the security benefits of 2FA, leading to costly support calls (estimated at $40-$70 per incident) or, worse, successful account takeovers (ATOs). The article will explore various authentication factors, analyze existing company strategies, and provide concrete recommendations for balancing security, usability, and cost-effectiveness in account recovery design.

Background

▶ Watch: Introduction: 2FA account recovery for consumer apps (0:00)

The necessity for well-designed account recovery stems from the inherent fragility of authentication factors in the real world. Users routinely forget passwords, lose or change phone numbers, misplace hardware security keys like YubiKeys, or upgrade devices without properly migrating authenticator apps like Google Authenticator or Authy. These common scenarios necessitate a pathway for legitimate users to regain access without compromising account security. Kelley Robinson aptly characterizes account recovery as an "alternative authentication system," fundamentally different from day-to-day login, as it involves reproving an identity to an account that already contains valuable data or funds. This distinction is crucial because it implies that recovery mechanisms must be designed with an equivalent, if not greater, level of scrutiny and security than primary authentication.

The risks associated with account recovery are substantial. If an attacker can successfully impersonate a legitimate user through a weak recovery process, they can bypass all primary authentication measures, including 2FA, leading to a full Account Takeover (ATO). This is not only a financial risk for users and companies but also a reputational one. Furthermore, managing account recovery is expensive. Robinson cites research indicating that a single account recovery support call can cost between $40 and $70, underscoring the economic incentive for robust self-service options.

Robinson breaks down authentication factors into three main categories, evaluating their suitability for account recovery:

1. Knowledge Factors (Something You Know):

• Examples: Passwords, security questions (e.g., mother's maiden name, first pet's name), specific account information (e.g., recent transactions).
• Pros: Easy to use and set up, cannot be physically lost. Security questions are often memorable.
• Cons: Passwords can be breached or reused. Security questions can often be guessed or socially engineered (e.g., finding someone's childhood street). Humans are forgetful.

1. Inherence Factors (Something You Are):

• Examples: Fingerprints, voice recognition, typing patterns.
• Pros: Cannot be lost or forgotten.
• Cons: Cannot be changed if breached, making implementation highly sensitive. Cloning fingerprints or voice can be a concern, limiting widespread support outside of on-device authentication.

1. Possession Factors (Something You Have):

• Examples: Phones (for SMS codes or authenticator apps), backup/recovery codes, hardware security tokens (YubiKeys).
• Pros: Generally more secure than passwords, harder to phish, less susceptible to data breaches.
• Cons: Users frequently lose or replace these items. Introducing these factors often adds initial setup friction, making universal adoption challenging.
• Specific Note on Backup Codes: While designed to be long and unique, Robinson hypothesizes that most users fail to store them securely or accessibly, rendering them useless in a recovery scenario. She points out that many services, like Instagram, offer insufficient guidance on how to store them, potentially leading users to email them to themselves (a risky practice if email is compromised) or simply neglect them.

The challenge, therefore, lies in designing a recovery system that leverages the strengths of multiple factors while mitigating their individual weaknesses, all while balancing security with user experience and operational costs.

Key Findings

▶ Watch: Evaluating authentication factors for account recovery (4:15)

Kelley Robinson's talk distills several crucial findings regarding the design of account recovery in a 2FA world, emphasizing that a one-size-fits-all approach is ineffective. The central premise is that account recovery is not a secondary login path but an independent, critical authentication system that demands its own robust security considerations.

1. Recovery is an "Alternative Authentication System" with Inherent Risk: Unlike primary login, recovery always involves reproving identity to an account that already possesses value. This makes it a high-stakes target for attackers and necessitates a design philosophy that prioritizes security and identity verification over mere convenience. The financial cost of manual recovery ($40-$70 per support call) further underscores the need for efficient and secure automated or semi-automated processes.

1. More Factors (3FA for 2FA) are Essential for Robust Recovery: The most straightforward and impactful finding is the recommendation to register more authentication factors than are strictly required for daily login. For users with 2FA enabled, effective recovery often necessitates "three-factor authentication" – two factors for everyday login, plus an additional, distinct factor (or method) specifically for recovery. This provides additional trusted data points to verify identity when a primary factor is lost, increasing confidence in the user's legitimacy and reducing the chance of full lockout.

1. No Single Factor is Sufficiently Secure or Usable for All Recovery Scenarios: Each authentication factor type (knowledge, inherence, possession) has significant pros and cons. Knowledge factors are easy but vulnerable to breaches and social engineering. Inherence factors are convenient but unchangeable if compromised. Possession factors are generally strong but susceptible to loss and introduce setup friction. Effective recovery systems must combine multiple factor types or multiple instances of possession factors to provide redundancy and resilience.

1. Context and Threat Modeling Dictate Recovery Strategy: The optimal account recovery strategy is highly dependent on the risk profile of the service. A cryptocurrency exchange like Gemini or a code repository like GitHub, protecting high-value assets or sensitive intellectual property, can justify significant friction (e.g., multi-day waiting periods, government ID verification) that a low-risk service like a cooking blog cannot. Understanding Account Takeover (ATO) costs and customer expectations is crucial for making appropriate investment decisions in recovery security.

1. User Onboarding and Education are Critical, but Often Neglected: Even the most secure recovery options, like backup codes or hardware keys, are useless if users don't set them up correctly or store them securely. Robinson highlights the poor usability of YubiKey onboarding in a 2018 study (e.g., Windows 10's 19% self-lockout rate), emphasizing that clear instructions, successful verification before activation, and timely prompts (e.g., before new iPhone releases) are essential for user success.

1. "Don'ts" Are As Important As "Dos": The talk strongly advises against practices that undermine 2FA security during recovery. Crucially, services should never allow recovery with only one factor when 2FA is enabled (e.g., falling back to password-only after a SIM swap bypasses SMS 2FA). Similarly, disabling 2FA entirely during a recovery process, even temporarily, creates a gaping vulnerability. These anti-patterns directly contradict the security posture 2FA aims to establish.

In essence, Robinson's findings advocate for a holistic, risk-aware approach to account recovery, treating it as a primary security concern rather than an afterthought, and designing it with layered defenses and user-centric education.

Technical Deep Dive

▶ Watch: Facebook's unique social recovery: trusted friends (15:00)

Kelley Robinson provides a comprehensive technical deep dive into designing effective account recovery systems, drawing from real-world examples and Twilio's experience. The core challenge is to verify a user's identity when their primary authentication factors are compromised or lost, without opening the door to attackers.

Authentication Factor Analysis for Recovery

Robinson begins by reiterating the strengths and weaknesses of different authentication factors in the context of account recovery:

• Knowledge Factors (Something You Know): While easy to set up and use (e.g., passwords, security questions), they are highly susceptible to breaches, reuse, social engineering, and simple forgetfulness. Security questions, like "mother's maiden name," are often discoverable. For recovery, these should ideally be combined with other, stronger factors.
• Inherence Factors (Something You Are): Biometrics like fingerprints or voice are convenient and cannot be lost. However, their immutability poses a high risk if breached, and cloning techniques, while "sci-fi," are possible, limiting their broad applicability for off-device recovery. They are best suited for on-device authentication where the biometric data never leaves the device.
• Possession Factors (Something You Have): Devices like phones (for TOTP apps or SMS) or hardware security tokens (e.g., YubiKeys) are generally more secure against phishing and data breaches. The main challenge for recovery is that users frequently lose or replace these items. Additionally, setting them up can introduce initial friction. Robinson specifically highlights recovery codes or backup tokens as a critical possession factor. While ideal in theory (long, unique), she hypothesizes that most users fail to store them securely or effectively, rendering them useless. Services should provide clear, actionable guidance on storage (e.g., "write them down," "save in a password manager," but not "email to yourself" due to email compromise risk).

Real-World Company Examples and Their Recovery Processes

Robinson analyzes several companies' approaches to illustrate both good and bad practices:

1. **E*TRADE (Questionable Example):**

• Problem: Uses a proprietary 2FA app where users append the TFA code to their password. The only way to reset 2FA upon changing phones is to call their call center.
• Major Flaw: The call center process reportedly requires no authentication to change 2FA. This effectively bypasses all security, making the 2FA itself almost moot for recovery purposes. E*TRADE presents a "worst of both worlds" scenario: high friction (phone call) with low security.

1. Authy (Twilio's Product):

• Approach: Requires 2FA for any account recovery attempt. If a user loses one factor, they must still use other registered factors to regain access.
• Key Features:
• Additional Factors: Users are encouraged to register multiple factors (e.g., multiple devices for Authy, a password, a phone number).
• Waiting Periods: Imposes a waiting period of 1 to 4 days, depending on available factors. This deters attackers and provides legitimate users time to dispute takeovers via email notifications.
• Risk-Adjusted Friction: Acknowledges that security products (like Authy) can impose more friction than, say, a cooking blog, as users expect and tolerate it.
• Phone Number Changes: Specific protocols for changing phone numbers, especially outside the US, given its commonality.
• Authy's Multi-Device Sync: Authy allows users to sync their authenticator app across multiple devices (e.g., phone and iPad). If a user loses their phone, they can approve a new device registration from an existing, trusted device. This acts as a secure in-app recovery method, leveraging a key-based authentication system.

1. GitHub:

• Approach: Provides extensive documentation and multiple recovery options, reflecting its high-risk user base (access to source code).
• Key Features:
• Recovery Tokens: Strongly encourages users to save recovery tokens as the easiest recovery path.
• SMS Fallback: Allows fallback to SMS if stronger TFA (TOTP or YubiKey) is enabled, which can be disabled by the user.
• Facebook Recovery Token: A unique option to store a recovery token via a linked Facebook account, leveraging Facebook's presumed accessibility.
• Extreme Measures: In some high-risk scenarios, GitHub has been known to propose unlinking email, creating a new account, and releasing the old username after six months of dormancy – an "extreme and unforgiving" scenario that highlights their commitment to security.

1. Facebook:

• Approach: Leverages its social graph for recovery.
• Key Feature: Trusted Friends: Users can nominate 3-5 friends to confirm their identity. This is ideal for products with a strong social or team component.
• Challenge: User setup for this feature can be challenging, as it's often buried in settings and requires active configuration.

Recommendations for Designing Account Recovery

Robinson provides actionable recommendations for developers:

1. Register More Factors Than Needed for Daily Login (3FA for 2FA): This is the most critical recommendation. When a user first signs up or during an authenticated session, prompt them to register backup methods beyond their primary 2FA. The more trusted factors available, the higher the confidence in identity verification during recovery. This doesn't necessarily mean three types of factors, but at least two methods of recovery (e.g., primary 2FA + recovery codes + a trusted device).

• Contextual Friction: A financial service like ING Bank might justify virtual video calls for new customer verification, while an e-retailer should not demand government IDs.
• Threat Modeling: Understand ATO costs and the value of accounts. A cryptocurrency exchange (Gemini) can impose more friction than a DoorDash account. Robinson quotes Cormac Harley: "users risk or they reject a lot of security advice for good reasons because following that advice takes more time than they might risk losing."

1. Be Intentional About Staff-Facilitated Recovery: Define clear policies on when and how support staff can assist with recovery. Acknowledging a personal anecdote where a Twitter DM allowed account reset with just a phone number and email (despite her full name not being linked to the profile), Robinson notes the trade-off between user convenience and security risk. Sensitive accounts should have stricter internal protocols.

1. Prompt Users to Confirm/Configure Recovery Options:

• Security Checkups: Regularly remind users to review and update their recovery methods (e.g., GitHub's security checkup prompts).
• Timely Reminders: Send proactive notifications around holidays or new iPhone releases, when users are likely to change devices, prompting them to save recovery codes or update backup information (e.g., Zapier's email).
• Evolving Features: Note that while Authy pioneered backup codes, other TOTP apps like Google Authenticator now offer token export features, but users still need to do the work to use them.

1. Design TFA Onboarding Well:

• Success Verification: Crucially, ensure users can successfully complete at least one authentication with a new factor before it is fully enabled. A 2018 study on YubiKey usability showed Google with 83% success, Facebook 32%, but Windows 10 had a staggering 19% self-lockout rate because it allowed enabling the factor without successful verification.
• Clear Documentation: Provide excellent documentation and a smooth workflow for factor setup.

1. Add Waiting Periods:

• Deterrence: Waiting periods (e.g., Authy's 1-4 days, GitHub's 3-5 days, Gemini's password reset waiting periods) deter attackers by slowing them down and provide legitimate users time to dispute fraudulent recovery attempts. This is a common and reasonable practice for high-value accounts.

What NOT to Do

Robinson concludes with critical "don'ts":

• Don't allow recovery with only one factor when 2FA is enabled: This is a major vulnerability, as seen with SIM swap attacks bypassing SMS 2FA. If a user forgets their password, they should still need their second factor and an additional backup factor for recovery.
• Don't disable 2FA during account recovery: This completely negates the purpose of 2FA. Robinson shares a personal experience where a service disabled her 2FA during recovery, leaving her account vulnerable despite having access to her authenticator app.
• Don't give up on 2FA: Despite the complexities, 2FA is highly effective. Google research shows that even SMS codes prevent 76% of targeted attacks. The goal is to implement it thoughtfully.

This detailed analysis underscores that account recovery is a complex, multi-faceted problem requiring careful consideration of factors, user behavior, threat models, and operational costs.

Demo / Proof of Concept

▶ Watch: Recommendation: Register more factors than needed (16:00)

This talk was primarily an analytical and prescriptive discussion rather than a live demonstration. Kelley Robinson presented and analyzed existing account recovery processes from various companies, including E*TRADE, Authy, GitHub, and Facebook, using screenshots and descriptions to illustrate her points and recommendations. There was no live demo or proof-of-concept code shown during the presentation.

Defensive Implications

▶ Watch: Q&A: Registering multiple Authy devices for recovery (28:40)

Kelley Robinson's insights offer critical defensive implications for any organization implementing or refining account recovery processes, especially those leveraging 2FA. Defenders must shift their mindset to view account recovery not as a secondary function, but as a primary alternative authentication system that requires robust, multi-layered security.

Here are the key defensive actions:

1. Enforce "3FA" for 2FA Recovery: The most crucial defensive strategy is to require more authentication factors for recovery than for daily login. If a user has 2FA enabled, their recovery path should ideally involve at least two distinct factors or methods. This might mean primary 2FA plus recovery codes, or a trusted device, or a combination of knowledge and possession factors. This redundancy significantly raises the bar for attackers.

1. Conduct Comprehensive Threat Modeling: Organizations must perform thorough threat modeling specific to their service's risk profile and the value of user accounts. A cryptocurrency exchange like Gemini justifies multi-day waiting periods for password resets and high-friction recovery, while a low-value content site might not. Understanding your Account Takeover (ATO) costs is essential for justifying the investment in more robust (and potentially more frictional) recovery mechanisms.

1. Prioritize Secure Backup/Recovery Code Management: If using recovery codes, defenders must provide explicit, actionable guidance on how users should store them. Discourage risky practices like emailing them. Consider integration with password managers or provide clear instructions for physical storage. The goal is to maximize the likelihood that users can actually use these codes when needed.

1. Implement Smart User Onboarding and Education:

• Verify Before Activate: Crucially, ensure that a user successfully authenticates with a new factor (e.g., a YubiKey) before it is fully enabled on their account. This prevents self-lockouts, as seen in the Windows 10 YubiKey study.
• Proactive Reminders: Leverage security checkups and timely email notifications (e.g., before major holidays or new phone releases) to prompt users to review and update their recovery options. This minimizes recovery incidents during high-change periods.

1. Establish Clear Protocols for Staff-Assisted Recovery: Define strict, documented policies for when and how support staff can facilitate account recovery. For sensitive accounts, this process should involve multiple checks and potentially require higher levels of authentication from the user (e.g., specific account details, trusted contact verification) to prevent social engineering attacks against support personnel. Avoid scenarios where a simple phone number or email is sufficient for high-value account resets.

1. Utilize Waiting Periods Strategically: Implement waiting periods (e.g., 1-5 days) for account recovery or significant account changes (like phone number updates). This provides a critical window for legitimate users to detect and dispute fraudulent takeover attempts, especially when combined with email notifications to all registered contact methods. This "slows down the attacker" and gives defenders time to react.

1. Avoid Critical Anti-Patterns:

• Never allow single-factor recovery when 2FA is enabled: This is a direct bypass of 2FA and makes accounts vulnerable to SIM swap attacks. Always require at least the second factor, plus an additional backup, for recovery.
• Never disable 2FA during recovery: Temporarily disabling 2FA creates a significant window of vulnerability. The recovery process itself must maintain the security posture of 2FA.
• Avoid proprietary, non-standard 2FA apps: These often lead to vendor lock-in and poor recovery experiences, as exemplified by E*TRADE's system. Favor open standards like TOTP where possible.

By adopting these defensive strategies, organizations can build account recovery systems that are resilient against attack, cost-effective to operate, and user-friendly for legitimate customers, ultimately upholding the security benefits of 2FA.

Key Takeaways

• Account recovery is an alternative authentication system, not just a fallback. It needs robust, independent design and security considerations, as it targets accounts with existing value.
• For 2FA-enabled accounts, aim for "3FA" for recovery. Users should register more factors than they need for everyday login to provide redundancy and increased confidence in identity verification during recovery.
• No single authentication factor is perfect for recovery. A combination of knowledge, inherence, and possession factors, or multiple instances of possession factors, should be used to build resilience.
• Context and threat modeling are paramount. The level of friction and security in recovery must align with the risk profile and value of the accounts being protected (e.g., cryptocurrency exchange vs. cooking blog).
• User onboarding and education are critical. Ensure users successfully verify new factors before activation and provide clear guidance on storing recovery codes. Proactive reminders (e.g., before device upgrades) can prevent lockouts.
• Implement waiting periods for recovery. These deter attackers and provide legitimate users time to detect and dispute fraudulent takeover attempts, especially when coupled with notifications.
• Avoid critical anti-patterns: Never allow single-factor recovery when 2FA is enabled, and never disable 2FA during the recovery process itself. These practices negate the security benefits of 2FA.

About the Speaker(s)

Kelley Robinson is an expert in Account Security at Twilio, a leading cloud communications platform. With over three years at Twilio, her work specifically focuses on supporting Twilio's account security products, including user verification, phone verification, and email verification. Her team's expertise has significantly evolved, particularly since Twilio's acquisition of Authy five years prior. Authy is a widely used, free consumer application for two-factor authentication, and Robinson's talk incorporates valuable lessons learned from running this product, especially regarding its account recovery options. Her experience spans working with developers and customers to address complex authentication challenges, making her a highly knowledgeable voice in the realm of online security.