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

Source: https://www.techinterview.org/post/3233475068/design-mobile-2fa-authenticator-app/
Updated: 2026-06-30 · techinterview.org

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:

- Each device has a master encryption key derived from a user passphrase (PBKDF2/Argon2)

- Secrets are encrypted with this key before upload

- The cloud stores ciphertext only

- 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.