We're on Product Hunt today! Leave a comment

Security Policy

We take the security of 2FA Authenticator seriously. Because this extension stores TOTP secrets, any vulnerability has direct impact on user account security across third-party services.

Reviewing this extension for your organisation? How it works covers the cryptography, key management, storage, permissions, network egress, the daily billing check-in, threat model and how to reproduce the published build.

Data Handling

We do not sell, license, or share user data with third parties, beyond the providers that run the service for us. TOTP secrets, account names and codes are stored locally in your browser and never reach our servers in a form we can read: Pro's optional cloud backup sends them end-to-end encrypted, under a key derived from a recovery code we never receive. Since 1.14.0 the extension checks in with api.authenticator.sh once a day, for the free plan and Pro, with an anonymous install id and a closed list of fields — the number of accounts, never which ones. The Privacy Policy lists every field, the providers and how long anything is kept.

Billing and licenses

The free plan's account limit and Pro rest on four invariants. Breaking one is a vulnerability:

  • • Nothing about an account leaves the device in a form we can read. The check-in carries a closed list of fields — a count of accounts, never a name, issuer, secret, code or site. Pro's cloud backup, which the user turns on, sends only ciphertext: the server never holds the key, refuses copies under any code but the license's current one, needs proof of the code to add or fetch copies, and the code or the license key to delete them.
  • • The limit can only stop an addition. No billing state can hide, lock, remove or alter an account, or block showing codes, export, backups, restoring or sync.
  • • No signed policy, no limit. Until a policy signed by a key the build trusts has been received for this installation, nothing is limited; after that, the limit is checked offline from the last such policy. An unreachable or misbehaving server can never lock anyone out.
  • • Tokens are verified, not trusted. Policies and licenses are ES256 JWS checked with WebCrypto against the public keys compiled into the build; a Chrome Web Store build trusts the production key only.

A way to get Pro without paying by editing the open-source code is not a vulnerability — the limit is not DRM. A way for one person to obtain or use anotherperson's license, or to make someone else's installation limited, is.

Reporting a Vulnerability

Please do not report security issues through public GitHub issues, the Chrome Web Store reviews, or social media. Instead, email security@authenticator.sh with a description of the issue, steps to reproduce, the affected version, and your name or handle if you would like public credit.

Response Timeline

  • Acknowledgment: within 72 hours
  • Initial assessment: within 7 days
  • Fix or mitigation timeline: within 14 days, depending on severity

If you do not receive a response within 72 hours, please follow up — your message may have been filtered.

Scope

In scope

  • • Browser extension code
  • • Build and release pipeline
  • • Storage of TOTP secrets and backups
  • • Cryptographic implementation
  • • Third-party dependency vulnerabilities
  • • The billing check-in and licenses: what the extension sends to api.authenticator.sh, and how it verifies the policy and license it receives

Out of scope

  • • Third-party services using TOTP
  • • Vulnerabilities in Chrome itself
  • • Social engineering of users
  • • Physical access attacks
  • • Denial of service

Safe Harbor

We will not pursue legal action against researchers who:

  • • Make a good-faith effort to comply with this policy
  • • Avoid privacy violations, data destruction, and service disruption
  • • Do not access or modify data beyond what is necessary to demonstrate the issue
  • • Do not exploit the vulnerability beyond confirming its existence
  • • Report the issue promptly and do not disclose it publicly before coordination

We follow coordinated disclosure. Please give us a reasonable window (typically 90 days, or sooner if a fix ships) before public disclosure. We credit reporters in release notes unless you prefer to remain anonymous.

Machine-readable contact: /.well-known/security.txt