重置密码。 而不是引发事故。

粘贴凭据的问题

粘进工单或聊天里的密码，比它自己的轮换活得更久：它躺在对话、工单历史、邮件存储以及每一份备份里，在账号早已变更之后仍可被检索。即使凭据是临时的，关于它的记录却不是 — 而「在帮助台档案里 grep 密码」是真实的攻击手法，正因为它奏效。

BurnPony 改变了什么

• 凭据从不停留在档案库里。给工单发一条 BurnPony 链接，而不是密码。对话里留下的是会焚毁的链接；秘密本身在你的手机上被加密，并在最后一次查看时或过期时从中继删除。
• 查看次数与工作流相匹配。一个用户看一次。若用户总在第一次搞砸，就给几次。最后一次允许的查看会原子地删除密文 — 两个并发请求也无法把只看一次的纸条撑大。
• 回执让闭环成立。开启公开的已读回执，工单就能基于事实关闭 — 纸条在 14:32 被打开 — 而不是基于沉默。
• 过期时间强制执行你的策略。必须当天使用的重置链接设为 1 小时或 8 小时过期，由服务器强制执行，而不是靠好言相求。
• 没有账号泛滥。收件人需要的是浏览器，而不是注册。外包人员、还没有邮箱的新员工、一次性的外部人员，都以同样的方式使用。

坦诚的局限

BurnPony 把一件东西 — 秘密 — 移出你的档案库。它不是 PAM 系统：没有保险库、没有轮换、没有超出你自己「已发送」标签的审计记录，也没有管理控制台。撰写纸条需要 App（iPhone 或 Android），这未必适合每一个工位。而且没有任何工具能阻止收件人复制屏幕显示给他的内容 — 把纸条与首次登录强制改密码搭配使用，正如你已经在做的那样。

一个明智的做法

• 用你平常的工具生成临时凭据，并设置首次使用时强制轮换。
• 把凭据 — 只放凭据 — 放进一张 BurnPony 纸条：查看 1–2 次、过期时间短、开启回执。
• 把链接粘进工单或聊天，用户名照常随工单传递，这样任何单一渠道都不完整。
• 回执到达时关闭工单；如果请求原来是假的，就从「已发送」标签把纸条烧掉。