2FA Secret Key Generator

Generate a cryptographically secure Base32 secret key for new 2FA setups. Generated entirely in your browser.

When do I need a new secret?

  • Setting up 2FA on a custom application or server.
  • Your existing 2FA secret was compromised.
  • Building a TOTP-based authentication system.

About This Tool

This tool generates a cryptographically secure random secret key in Base32 format, the standard encoding used by all TOTP (Time-based One-Time Password) authenticator apps. The key is generated using the browser's crypto.getRandomValues() API, which produces true random data from the operating system's entropy pool. Use this when building a new 2FA-enabled application or when manually configuring two-factor authentication that requires you to supply your own secret.

How to Use

  1. Choose your preferred key length, 160-bit (32 characters) is the TOTP standard, and 256-bit offers extra security.
  2. Click Generate Secret. A new random Base32 key appears instantly.
  3. Copy the key and store it securely, this is your shared secret between the server and the authenticator app.
  4. Use the QR Code Generator to turn the secret into a scannable QR code for your authenticator app.

Common Use Cases

  • Setting up 2FA on self-hosted software: apps like Nextcloud, Vaultwarden, and pfSense sometimes require you to supply your own secret rather than generating one server-side during setup.
  • Building a custom login system: generate a properly random seed for each new user account when implementing your own TOTP-based two-factor authentication.
  • Replacing a compromised secret: if a secret key was accidentally logged in plaintext or exposed in a config file, generate a fresh one immediately rather than waiting on a vendor's key rotation flow.
  • Creating test fixtures for QA: generate several known Base32 secrets to use as fixed inputs when writing unit tests for a 2FA implementation.
  • Provisioning a hardware TOTP token: some hardware tokens only accept a manually typed Base32 key rather than scanning a QR code, so a clean freshly generated key avoids transcription mistakes.

TOTP vs HOTP, and Why SHA1 Is Still the Default

TOTP (Time-based One-Time Password, RFC 6238) derives each code from the current Unix time divided into 30 second windows, so it requires the server and the authenticator app to have reasonably synced clocks but never needs the two sides to track how many times a code has been used. HOTP (HMAC-based One-Time Password, RFC 4226) instead uses an incrementing counter, which avoids clock dependency entirely but can desynchronize if a code is generated on the device without ever being submitted to the server. Almost all consumer 2FA today uses TOTP because clock drift is easier to tolerate than counter desync across multiple devices. On the algorithm side, RFC 6238 defaults to HMAC-SHA1, and even though SHA1 is considered broken for collision resistance in other contexts, its use here is inside an HMAC construction, which remains secure for this purpose. Most authenticator apps only support SHA1 and will silently produce incorrect codes if a server is configured for SHA256 or SHA512.

Troubleshooting

The secret generates fine but my server and authenticator produce different codes: confirm both sides agree on algorithm, digit count, and time period, and check that your server's clock is not drifting. TOTP typically tolerates only about 30 to 60 seconds of clock skew.

A 256-bit key gets rejected by an older app: some legacy authenticator apps only accept the standard 160-bit (20-byte) length. Stick with the default option for maximum compatibility unless you have confirmed the target app supports longer keys.

The Copy Secret button does not seem to do anything: clipboard access requires a secure HTTPS context and, in some browsers, an explicit permission grant. If it silently fails, manually select the text and copy it instead.

The QR code link uses a generic issuer name: the Generate QR Code button passes only the secret to the QR Generator page. Fill in the correct issuer and account fields directly on that page after it opens.

Frequently Asked Questions

What is a Base32 secret key?

A Base32 secret key is a random string encoded using only the characters A to Z and 2 to 7. It's the shared secret between your server and your authenticator app used to compute time-based one-time passwords (TOTP) defined in RFC 6238.

How long should my secret key be?

RFC 4226 recommends a minimum of 160 bits (20 bytes, 32 Base32 characters). For new applications, 256 bits (32 bytes, 52 Base32 characters) provides a comfortable security margin. Keys shorter than 128 bits are considered weak.

Can I use this key with Google Authenticator?

Yes. Generate the key here, then use the QR Code Generator tool to create a scannable QR code, and scan it with Google Authenticator, Authy, or any TOTP app. The generated codes will be valid.

What's the difference between TOTP and HOTP secrets?

The secret key itself is the same Base32 format for both. TOTP derives codes from the current time in 30 second windows, while HOTP derives codes from an incrementing counter shared between server and device. TOTP is far more common because it tolerates clock drift better than HOTP tolerates counter desync.

Is SHA1 safe to use for 2FA even though it's considered broken elsewhere?

Yes. The collision attacks that broke SHA1 for things like certificate signing do not apply to its use inside HMAC-SHA1, which is what TOTP relies on. HMAC-SHA1 remains cryptographically sound for one-time password generation, which is why it's still the RFC 6238 default and the algorithm nearly every authenticator app supports.