Design a Mobile 2FA Authenticator: Storage, Sync, and Security

By /
⏱ 2 min read

A mobile authenticator app is a small surface with disproportionately strict requirements. The user trusts it with the second factor for every account they own — losing it can lock them out of their digital life. The interview tests whether you understand TOTP cryptography, secure storage, sync vs single-device tradeoffs, and the brutal recovery problem.

Functional requirements

  • Add a TOTP account (scan QR code or manual entry)
  • Display 6-digit codes that rotate every 30 seconds
  • Sync across user’s devices (optional but increasingly expected)
  • Recovery from lost device
  • Backup to cloud (encrypted)

How TOTP works

Time-based One-Time Password (RFC 6238). Each account has a shared secret with the service. The code is HMAC(secret, current_time / 30) truncated to 6 digits.

Both the server and the client must agree on the time. Most clients allow ±1 step (30 seconds) of clock skew. Cleanly synchronizing time is the primary correctness concern.

Storage

The shared secret is the most sensitive thing in the app. It must be stored securely:

  • iOS: Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly
  • Android: Keystore-backed encryption, EncryptedSharedPreferences

Never log the secret. Never let it leave the secure store.

Adding accounts

Most accounts are added via QR code. The QR encodes an otpauth URI:

otpauth://totp/Issuer:user@example.com?secret=ABC...&issuer=Issuer

Manual entry is the fallback. The app displays a confirmation code from the secret to verify the user enrolled correctly.

Sync across devices (the hard problem)

Single-device authenticators (Google Authenticator pre-2023) are simpler: lose the phone, lose access. Multi-device authenticators (Authy, 1Password, modern Google Authenticator) sync secrets across the user’s devices.

Sync is much harder because:

  • Secrets must remain encrypted at rest in the cloud
  • The cloud should not be able to decrypt them — end-to-end encryption is mandatory
  • Recovery requires a recovery passphrase or trusted device

Implementation:

  1. Each device has a master encryption key derived from a user passphrase (PBKDF2/Argon2)
  2. Secrets are encrypted with this key before upload
  3. The cloud stores ciphertext only
  4. New devices are added by entering the same passphrase + device verification

Recovery

Three recovery modes:

  • Backup phrase: the user records a 24-word seed phrase. Lose the phrase, lose access.
  • Cloud backup with master password: need the password to restore.
  • Trusted device: add new device by approving from existing device.

None are perfect. Make recovery options clear during onboarding.

Push-based 2FA

Some authenticators support push approval (Duo, Microsoft Authenticator). Server pushes “Approve login from X?”; user taps Approve in the app.

Implementation: app registers with push notification provider. Server pushes a payload containing the request. App verifies a signature from the server before showing the prompt.

Frequently Asked Questions

What if the user’s clock is wrong?

Codes will not match. Some apps fetch NTP time as a fallback. Most rely on the device clock and require the user to fix it.

Should I let users export their secrets?

For migration purposes, yes — but with explicit warnings. Google Authenticator added export-via-QR in 2020 because losing access to all your accounts was a known problem.

How do you prevent someone with my unlocked phone from seeing my codes?

App-level lock (separate PIN/biometric within the authenticator app). Most authenticators offer this as opt-in. Defense in depth — your phone’s lock should be the main barrier.

Scroll to Top