SHARED SECRET / SECOND FACTOR / PROVISIONING
Authenticator setup and TOTP QR codes
Authenticator configuration QR code
Parameter envelope · JSON
ORIGINS / STANDARDS / OPERATIONS
Standards, background and practical limits
Why a second factor needs a shared secret
Authentication distinguishes what you know, what you possess and biometric characteristics. Asking for a changing code after a password is a two-step process; it is two-factor authentication only when independent factors are involved. TOTP commonly serves as a possession-based second factor, with a shared secret that needs its own lifecycle. It is neither content encryption nor public-key authentication.
RFC 6238 (2011) builds on RFC 4226's HOTP by replacing a counter with a time step. The service and authenticator share a key, algorithm and interval, using HMAC and dynamic truncation to produce codes. SHA-1, six digits and 30 seconds are common. The code changes; the underlying shared secret does not change with each refresh.
The QR code carries an otpauth URI containing the secret, issuer, account label and parameters. It avoids manual transcription when you have a backup text secret or are testing your own service. A successful scan means the authenticator imported the configuration, not that a service accepted it or enabled two-factor authentication. Labels are for display. This tool is unrelated to Pathadd's Geek Communication access gates.
Make a QR code from an existing secret, or create a test configuration
Enter the original service's RFC 4648 Base32 secret, issuer and account label to draw a QR code locally. Defaults favor common compatibility; advanced parameters must match the service. Base32 represents bytes and does not protect the secret. HMAC-SHA1 here has a different security role from legacy signatures that depend on collision resistance.
Alphabet, canonical padding and final unused bits are checked. Lowercase and space grouping are allowed. No zero-padding, truncation or username-derived secrets are used. The local qrcode library draws the image without an online QR service. Secrets are neither uploaded nor saved automatically; live one-time codes are not displayed.
Test configurations are for testing only, with no service holding the other copy. The browser securely generates a 20-byte secret labeled Pathadd Test / local-test. It is not bound to a website, account or server-side verifier, and Pathadd does not save or hold it. Scanning gives the authenticator a copy that can produce codes, but no service automatically accepts them.
A real deployment needs generation, trusted distribution, code-based enrollment confirmation, controlled backup, recovery, re-enrollment and revocation. If the secret leaks, revoke it and enroll again at the original service. Deleting a QR code locally or refreshing this page does not revoke the service's copy.
Limits: no third-party enrollment or secret recovery
An email address, username or website URL cannot produce a valid secret for that account. The original service must provide the secret and confirm enrollment with a code. A random test secret has no real authentication purpose unless you separately configure your own service to accept it.
The QR code, URI and secret have the same sensitive value. Anyone with a copy can produce the same codes. Do not share them publicly, upload screenshots or use online QR websites. Export requires explicit consent. Clearing the page removes neither downloads nor copies in the clipboard, phone or authenticator cloud sync. Browser extensions, device security and authenticator backup policies are outside Pathadd's control.
Authenticators may ignore advanced parameters, and device clock errors can cause failures. TOTP is not bound to a website origin and remains vulnerable to phishing and real-time relay. Passkey/WebAuthn is a different public-key scheme, not an equivalent security guarantee. This tool handles TOTP configuration only: 16-64-byte secrets, 6/8 digits and 30/60-second periods. It supports neither HOTP, QR import nor server-side verification.
Standards: RFC 6238 / TOTP · RFC 4226 / HOTP · RFC 4648 / Base32 · Key URI Format
Why a second factor needs a shared secret
Authentication distinguishes what you know, what you possess and biometric characteristics. Asking for a changing code after a password is a two-step process; it is two-factor authentication only when independent factors are involved. TOTP commonly serves as a possession-based second factor, with a shared secret that needs its own lifecycle. It is neither content encryption nor public-key authentication.
RFC 6238 (2011) builds on RFC 4226's HOTP by replacing a counter with a time step. The service and authenticator share a key, algorithm and interval, using HMAC and dynamic truncation to produce codes. SHA-1, six digits and 30 seconds are common. The code changes; the underlying shared secret does not change with each refresh.
The QR code carries an otpauth URI containing the secret, issuer, account label and parameters. It avoids manual transcription when you have a backup text secret or are testing your own service. A successful scan means the authenticator imported the configuration, not that a service accepted it or enabled two-factor authentication. Labels are for display. This tool is unrelated to Pathadd's Geek Communication access gates.
Make a QR code from an existing secret, or create a test configuration
Enter the original service's RFC 4648 Base32 secret, issuer and account label to draw a QR code locally. Defaults favor common compatibility; advanced parameters must match the service. Base32 represents bytes and does not protect the secret. HMAC-SHA1 here has a different security role from legacy signatures that depend on collision resistance.
Alphabet, canonical padding and final unused bits are checked. Lowercase and space grouping are allowed. No zero-padding, truncation or username-derived secrets are used. The local qrcode library draws the image without an online QR service. Secrets are neither uploaded nor saved automatically; live one-time codes are not displayed.
Test configurations are for testing only, with no service holding the other copy. The browser securely generates a 20-byte secret labeled Pathadd Test / local-test. It is not bound to a website, account or server-side verifier, and Pathadd does not save or hold it. Scanning gives the authenticator a copy that can produce codes, but no service automatically accepts them.
A real deployment needs generation, trusted distribution, code-based enrollment confirmation, controlled backup, recovery, re-enrollment and revocation. If the secret leaks, revoke it and enroll again at the original service. Deleting a QR code locally or refreshing this page does not revoke the service's copy.
Limits: no third-party enrollment or secret recovery
An email address, username or website URL cannot produce a valid secret for that account. The original service must provide the secret and confirm enrollment with a code. A random test secret has no real authentication purpose unless you separately configure your own service to accept it.
The QR code, URI and secret have the same sensitive value. Anyone with a copy can produce the same codes. Do not share them publicly, upload screenshots or use online QR websites. Export requires explicit consent. Clearing the page removes neither downloads nor copies in the clipboard, phone or authenticator cloud sync. Browser extensions, device security and authenticator backup policies are outside Pathadd's control.
Authenticators may ignore advanced parameters, and device clock errors can cause failures. TOTP is not bound to a website origin and remains vulnerable to phishing and real-time relay. Passkey/WebAuthn is a different public-key scheme, not an equivalent security guarantee. This tool handles TOTP configuration only: 16-64-byte secrets, 6/8 digits and 30/60-second periods. It supports neither HOTP, QR import nor server-side verification.
Standards: RFC 6238 / TOTP · RFC 4226 / HOTP · RFC 4648 / Base32 · Key URI Format