Twilio confirms data breach after hackers leak 33M Authy user phone numbers

Original Article ↗ Hacker News Discussion ↗

Twilio has confirmed that an unauthenticated API endpoint exposed data for 33 million Authy accounts, including associated phone numbers, prompting renewed criticism of phone numbers as an identifier for two-factor authentication. Commenters debate the security value of SMS- and phone-based 2FA, the risks of tying 2FA to centralized cloud services, and the difficulty of migrating away from Authy due to its limited export options. Many recommend moving to open-source or password-manager–integrated TOTP and hardware keys, and highlight better engineering practices—such as secure-by-default endpoints and systematic auth testing—to prevent similar breaches.

Reactions to the Authy / Twilio Breach

  • Many see this as final confirmation to abandon Authy, especially given its reliance on phone numbers and previous issues.
  • Others are resigned, saying their numbers are already in so many leaks that this one changes little.
  • Several criticize Twilio’s overall decline in reliability and security culture and call for stronger legal/financial penalties for such breaches.

Phone Numbers, SMS, and 2FA

  • Strong chorus: stop using phone numbers for authentication or 2FA, because of SIM swapping and their role as a universal identifier.
  • Counterpoint: some services (banks, governments) still mandate phone-based 2FA, so users are stuck.
  • Debate over sensitivity of phone numbers: some argue they used to be public; others note they are now an ID and 2FA channel, so leaks are much more dangerous.

Authy Design Critiques

  • Authy’s requirement for a phone-number–based account is widely viewed as “against the spirit of 2FA.”
  • Multi-device + SMS recovery is seen as a major risk; suggested mitigations are:
    • Disable multi-device entirely.
    • Enable it briefly to add backup devices, then disable.
  • Some note Authy also stores historical tokens and makes account deletion slow and user-hostile.

Migrating Away from Authy

  • Export is intentionally hard; official clients don’t provide seed export.
  • Workarounds:
    • Old Authy desktop versions plus Chrome devtools + scripts.
    • Third‑party tools (e.g., CLI that registers a dummy device and exports otpauth URIs).
  • Many ended up re-enrolling TOTP on each site manually; some report doing this for 50–700+ accounts.

Alternatives and Storage Strategies

  • Standalone / open-source options mentioned:
    • Aegis, Ente Auth, 2FAS, Authenticator Pro, OTP Auth (iOS), KeePassXC / KeePassDX, andOTP (unmaintained), oathtool, YubiKey Authenticator.
    • Raivo is explicitly warned against after ownership change and data loss incident.
  • Password-manager TOTP:
    • Bitwarden, 1Password, Apple Passwords, KeePass-based tools often used.
    • Some like the convenience; others dislike storing password and 2nd factor together and prefer separate apps or separate vaults.

Value of 2FA and Threat Models

  • Some argue SMS 2FA is barely better than no 2FA and that strong unique passwords suffice.
  • Others insist TOTP/WebAuthn is a significant security improvement; the core problem here is Authy’s account model, not 2FA itself.
  • Mixed practices: some keep TOTP only on hardware keys or offline devices; others accept reduced separation for usability.

Spam and Broader Phone-System Concerns

  • Multiple commenters report spikes in spam calls/texts and see leaks like this as feeding that ecosystem.
  • There’s extended discussion of how phone spam, weak regulation, and telecom incentives are degrading PSTN’s usefulness, pushing people to app-based calling.

Security Engineering Lessons (Unauthenticated Endpoint)

  • The breach stemmed from an unauthenticated endpoint exposing Authy account metadata.
  • Consensus: encryption-at-rest wouldn’t help; the issue is access control and rate limiting.
  • Suggested practices:
    • Secure-by-default frameworks where endpoints must explicitly declare public access.
    • Middleware/decorators that require auth on all endpoints unless explicitly allowed.
    • Automated tests that verify each endpoint rejects unauthenticated and unauthorized requests.
    • Endpoint inventories plus scripts that probe for endpoints accidentally left open.
    • In some cases, putting sensitive APIs behind certificate-based private overlays.