平台绑定页那张二维码里装了什么
二维码不是码,是「账号名片」
扫码绑定扫进去的不是某个 6 位数字,而是一段结构化文本——把账号的绑定信息打包成一条 URI,再用二维码编码呈现。标准格式(otpauth)大致长这样:
otpauth://totp/平台名:账号名?secret=设置密钥&issuer=平台名
逐段拆开:
| 段 | 内容 | 对应操作 |
|---|---|---|
totp | 类型:基于时间 | 手动添加时的「基于时间 / 基于计数」选择 |
平台名:账号名 | 条目默认显示名 | 添加时的账号名称输入框 |
secret=… | 共享密钥本体 | 手动添加时粘贴的「设置密钥」 |
issuer=… | 发行方标识 | 界面上显示的平台署名 |
所以手动输密钥与扫码是同一件事的两种录入方式:二维码易扫但需要摄像头与面对面的屏,密钥难抄但一个字符就能跨设备传递。
这解释了几件日常的事
- 为什么截图二维码等于泄露密钥:图里就有
secret=,能读码的应用都能把它提出来(密钥习惯第四条); - 为什么跨品牌扫通用:otpauth 是开放约定,各家验证器都按同一结构解析(二维码规则里单账号码的兼容性);
- 为什么多账号导出码不通用:谷歌的批量迁移码用的是另一套私有打包格式(含批次编号),不在 otpauth 约定内。
迁移二维码与绑定二维码的区别
绑定二维码:平台 → 验证器,载荷一把新密钥;迁移二维码:验证器 → 验证器,载荷一批已有密钥(约十把一批,十账号上限)。两者的安全分量相同——都是密钥本体,出示场景之外不留存、不外传。
一句延伸
正因为二维码只是「文本的图形化」,理论上所有环节(绑定、导出、导入)都可以退化为字符操作——各类验证器工具的「从文本导入」功能正是这么来的。理解这层,验证器的所有输入输出就都不神秘了。