Security Model

What this tool actually does

2FA Gen computes TOTP codes using the Web Crypto API, a cryptographic engine built into your browser. You paste a Base32 secret, the browser derives an HMAC from that secret and the current time, and the result is truncated into a six-digit code exactly as RFC 6238 specifies.

Everything in that sentence happens inside the tab. There is no API call, no server-side computation, and no logging, because there is no server-side component to this feature at all. The page is static files served by nginx.

Verify it yourself in ten seconds

Do not take our word for any of this. Two tests settle it:

1. The network test. Open your browser's Developer Tools, switch to the Network tab, then generate a code. After the initial page load you will see zero requests. If a secret were being transmitted, it would appear here.
2. The offline test. Load this page, then disconnect from the internet entirely — turn off Wi-Fi, unplug the cable. Generate a code. It still works, and it still matches your authenticator app. Software that needs a server cannot do that.

Both tests work on any page of this site, in any browser, with no special tooling.

The honest limitation

Here is what most tools in this category will not tell you.

The security of any TOTP system rests entirely on the secret staying secret. Pasting that secret into a web page — any web page, including this one — means trusting that the page you loaded is the page the operator intended to serve. That trust is well founded most of the time and it is not absolute. A compromised server, a hijacked domain, or a malicious browser extension with access to the page could change what the code does between one visit and the next.

So we will say plainly what the incentives discourage:

• For your bank, your primary email, your password manager, or your crypto exchange — use a hardware security key or a dedicated authenticator app on a device you control. Not this. Not any web-based generator.
• This tool is well suited to accounts where the convenience genuinely outweighs the risk: shared team logins, testing and development, throwaway or low-value accounts, recovering access when your phone is unavailable, or verifying that a secret you were given actually works before you commit it to an authenticator app.

That is a narrower recommendation than our competitors make. We think it is the correct one, and a tool that tells you when not to use it is worth more than one that does not.

How the page defends itself

• HTTPS only. The Web Crypto API is unavailable in an insecure context, so the tool refuses to run over plain HTTP rather than silently degrading. HTTP requests are redirected to HTTPS.
• No third-party code. The page loads no external scripts, no fonts, no analytics, no advertising SDKs, no CDN dependencies. Every byte comes from this domain. There is no supply chain to compromise because there is no supply chain.
• Content Security Policy and framing protection. The server sends a restrictive CSP along with X-Frame-Options, so the tool cannot be embedded in another site and used to phish your keys under someone else's branding.
• No persistence. Your secret exists in JavaScript memory for the life of the tab. There is no cookie, no localStorage, no sessionStorage, no IndexedDB, and no database. Closing the tab is a complete erasure.
• Nothing in the URL. Your key is never placed in a query string, so it cannot end up in browser history, a bookmark, a referrer header, or a server access log.

What we cannot protect you from

A clear threat model has to include its own boundaries:

• Malware on your device. A keylogger or a compromised operating system sees your secret regardless of how carefully this page behaves.
• Malicious browser extensions. Extensions with permission to read page content can read anything you type into any page.
• A phishing site imitating this one. Check the address bar. The only legitimate address is 2fagen.com.
• A secret that was already exposed. If your Base32 seed leaked before you arrived here — screenshotted into a chat, emailed, stored in a shared document — no generator can undo that. Re-enrol the account and get a new secret.
• A wrong clock. TOTP codes are derived from the current time. If your device clock drifts more than about thirty seconds, codes will be rejected. This is a correctness limit rather than a security one, but it is the most common cause of a valid key producing rejected codes.

Cryptographic details

For readers who want the specifics rather than the reassurance:

• Algorithm: HMAC-SHA-1 by default, with SHA-256 and SHA-512 supported. SHA-1 remains correct for HMAC use; the collision attacks that broke SHA-1 for signatures do not apply to HMAC constructions, which is why RFC 6238 still specifies it and why nearly every service still issues SHA-1 secrets.
• Time step: 30 seconds by default, configurable through an otpauth:// URI up to 300 seconds.
• Digits: 6 by default; 7 and 8 are supported.
• Truncation: dynamic truncation exactly as specified in RFC 4226 §5.4.
• Counter: 8-byte big-endian, which keeps the implementation correct past the 2038 signed-32-bit boundary.
• Key handling: the Base32 secret is decoded to raw bytes and imported as a non-extractable CryptoKey, so the key material cannot be read back out of the browser's crypto subsystem by page script.

The implementation is verified against all eighteen published test vectors in RFC 6238 Appendix B — every timestamp across all three hash algorithms — plus the full range of Base32 key lengths. If those vectors pass, the arithmetic is correct against the published standard, which is a stronger claim than "it seems to work".

Reporting a vulnerability

If you find a security issue, we want to hear about it before anyone else does.

Write to security@2fagen.com with enough detail to reproduce the problem. We aim to acknowledge within 72 hours and will keep you updated while we work on a fix. We will credit you when the fix ships unless you prefer otherwise.

Please do not run automated scanners against the site — they generate noise without finding anything a static site is vulnerable to. Manual reports about the cryptography, the page's handling of secrets, or the server configuration are genuinely welcome.

We do not currently operate a paid bug bounty.

Changes to this page

Security claims should be dated. Material changes to this page and to the tool are recorded in the changelog.

Last reviewed: 10 September 2026