验证器图标不对？为什么图标根本证明不了什么
图标缺失并不能说明谁掌握了你的第二因素。请通过账户核实注册信息，绝不要为了修图而上传二维码。
本该显示品牌图标的地方出现灰色方块，看起来确实吓人，但恰恰不该据此采取行动。验证器画出的图片只是由条目中标签派生出的显示细节，而真正关乎安全的问题是：该条目里的密钥是否属于你的账户。把这两件事分开，才能把外观层面的修补和凭据事件区分开来；它也能阻止那种让情况更糟的修补。
图标和密钥回答的是不同问题
验证器条目由一条密钥 URI 生成，其中携带共享密钥以及账户标签和发行方名称。应用会根据它认识的发行方绘制图标，无法识别或被改动的发行方只会得到一个通用图案。这个显示结果不会告诉你还有谁持有该密钥的副本，正确的图标也不能证明该条目只属于你。请把显示结果当作关于标签的提示，而不是关于保管的结论。
反过来同样成立，而且这个方向更危险：一个有说服力的图标，比缺失的图标证明的东西更少。
| Observation | What it supports | What it cannot support |
|---|---|---|
| Logo missing or wrong | The issuer string was not recognised | Any conclusion about secret disclosure |
| Logo correct | The issuer string matched a known name | Any conclusion about who else enrolled |
| Codes rejected by the service | A real mismatch between entry and account | Which of the two changed |
绝不要为了修图而重新注册
网上流传的修补办法是重新生成二维码，也就是把密钥导出并交给另一个工具处理。这把显示问题变成了泄露，因为导出内容正好包含攻击者生成有效验证码所需的全部材料。把它上传到网页生成器，等于用一个更漂亮的图标把第二因素交给第三方。
如果账户仍然能验证通过验证码，说明注册完好，显示问题只是外观层面。请查阅验证器自身关于发行方标签和图标匹配的文档，然后别去动那条条目。为了强求一个图标而修改标签，是出于与身份验证毫无关系的理由改动条目。
请把原始二维码图片、未经处理的密钥 URI 以及任何手动输入的密钥，挡在工单、聊天记录、截图和公开问题跟踪之外。一张设置页面的截图，往往包含比拍摄者预想更多的信息。
当密钥确实已经泄露
请把泄露当作一次独立事件，用独立流程应对。使用服务方支持的更换流程注册新的验证器，确认新条目能生成被接受的验证码，再到服务器端注销旧的注册。只在本地删除条目并不会移除服务器端的注册，因此已泄露的密钥仍可能继续有效，直到你通知服务方。本地删除与服务器状态之间的这段落差，正是大部分风险的所在。
顺序在这里很重要。先注册替代品、完成验证，然后再移除旧的那个，因为多数服务在最后一个因素消失时会把你就此锁在外面。恢复代码也应纳入这个顺序，它们是手机不可用时的兜底路径。
检查同一个密钥是否在其他地方也用过。被粘贴进生成器的密钥 URI 已经离开了你的掌控，在注册被替换之前，它背后的账户都应按共享处理。
求助请求应当描述显示问题，而不要附带验证码或设置材料。任何与账户相关的内容都该走服务商已验证的渠道，而不是公开帖子。
删除之前先留好恢复路径
在移除任何仍在工作的条目之前，先确认存在一条经过批准的恢复路径，并且你确实能用它。以被锁在外面收场的外观修补，比图标不对更糟；而当唯一已注册的设备就是正在被编辑的那台时，被锁在外面很常见。
可接受的条件很窄：账户与验证器之间存在经过验证的关联，且注册材料保持私密。熟悉的徽标不属于这个条件，它缺失也不构成已遭入侵的证据。
密钥 URI 格式本身记录在 Google Authenticator 密钥 URI 规范 中，它也提醒我们：载荷里装的是密钥，不是图标。在从一条输不起的条目里导出任何东西之前，先读一读它。