SHARED SECRET / SECOND FACTOR / PROVISIONING
验证器配置与 TOTP 二维码
运算结果
参数封装 · JSON
ORIGINS / STANDARDS / OPERATIONS
密钥体系：标准、背景与工程边界
工程问题：第二因素认证，为什么需要一份共享秘密
现代认证区分你知道的秘密、你持有的验证器以及生物特征。密码之后再要求动态验证码，是常见的两步验证流程；只有结合独立的认证因素，才构成双因素认证。TOTP 通常作为持有验证器的第二因素，是现代密钥与认证体系中共享秘密生命周期的重要一环，不是内容加解密，也不是公钥身份认证。
RFC 6238（2011）在 RFC 4226 的 HOTP 基础上，以时间步替换计数器。服务端与验证器持有同一密钥、使用一致的算法和时间步长，通过 HMAC 与动态截断计算验证码。常见配置是 SHA-1、六位、30 秒；验证码会刷新，底层共享密钥并不随每次刷新而改变。
二维码只是载体：它把共享密钥、服务名称、账号标签和参数编码成 otpauth URI。只有备用文字密钥，或自建服务需要测试验证器配置时，手工输入容易出错。扫码成功只说明手机导入了配置，不说明服务端已经绑定，更不会凭空为任何账号开启双因素认证。标签只用于显示。本工具与本站极客通信门控系统没有关联。
方案：已有配置转二维码，或生成纯测试配置
输入原服务提供的 RFC 4648 Base32 密钥，填写服务名称和账号标签，在本地生成验证器配置二维码。默认采用常见兼容参数；高级参数必须与原服务一致。Base32 是字节表示，不会保护密钥。这里的 SHA-1 用于 HMAC，与依赖抗碰撞性的旧签名用途不同。
本页检查字母表、规范填充和末尾有效位，允许小写及空格分组，不补零、不截断、不从用户名推导秘密。二维码由本地 qrcode 库绘制，不调用在线二维码服务；页面不上传、不自动保存密钥，也不显示实时验证码。
生成测试配置：纯测试用，密钥无其他载体承接。浏览器使用安全随机源生成 20 字节密钥，标签为 Pathadd Test / local-test。未与任何网站、账号或服务端验证系统绑定，本站不保存、不托管、不承接该密钥。扫码后验证器会持有一份副本并能产生验证码，但没有任何服务自动接受这些验证码。
真实系统需要完成密钥生成、可信分发、验证码确认绑定、受控备份、丢失恢复、重新绑定与撤销。共享秘密泄露后，应在原服务撤销旧配置并重新绑定；本地删掉二维码或刷新页面，不等于服务端已撤销。
限制：无法开通第三方验证，也不能恢复遗失密钥
无法根据邮箱、用户名或网站地址生成该账号的有效验证配置。真实绑定必须由原服务提供密钥，并到原服务输入动态验证码确认。随机测试密钥除非由你自建的服务另行配置，否则没有真实认证用途。
二维码、配置 URI 和密钥具有相同的秘密价值；拿到副本的人也能生成相同验证码。请勿公开分享、上传截图或交给在线二维码网站。导出需要明确确认风险，页面清除不会删除下载文件、剪贴板、手机或验证器云同步中的副本。浏览器扩展、终端安全及验证器的备份同步策略不在本站控制范围内。
不同验证器可能忽略或不支持高级参数，设备时钟偏差也会造成验证失败。TOTP 不与网站来源绑定，仍可能被钓鱼或实时中继；Passkey / WebAuthn 是不同的公钥认证方案，不能把两者安全能力等同。本工具不是认证服务，仅处理 TOTP 配置，接受 16–64 字节密钥、6/8 位和 30/60 秒，不支持 HOTP、扫码导入或服务端验证。
标准入口：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