我们如何保护您的 Bot Token

在使用 BotShade 时，您最关心的恐怕就是 Bot Token。一旦泄露，机器人可能被劫持，服务器也可能被破坏。正因如此，我们想坦率地告诉您：我们把它存放在哪里、如何存储、守护的边界在哪里，以及 我们决定不做哪些事。

谈论安全时，如果只罗列结论往往会显得枯燥乏味。本文中，我们会尽量连同 “为什么这样设计” 的思路一起分享。

本文涉及以下内容：

• 究竟什么是 Bot Token
• 当您托付 Token 时会发生什么
• 存储时如何保护
• 不同 Bot 之间如何隔离
• 传输过程中的防护
• 谁能接触到 Token
• 万一出事的应对
• 我们刻意不做的事
• 我们无法覆盖的部分，以及希望您配合的事

究竟什么是 Bot Token

Bot Token 是您在 Discord 开发者门户创建机器人时获得的一串长字符串。它是机器人向 Discord 表明 “我就是这个 Bot” 的凭据，可以理解为 专属于这个机器人的密码。

任何持有该 Token 的人，都能以这个机器人的身份做任何事：发送消息、分配身份组、封禁成员、修改服务器设置——只要在机器人被授予的权限范围内，全部可以做到。这正是 Token 被称为 “Discord 机器人中最敏感的一项信息” 的原因。

使用 BotShade 这类机器人平台，本质上就是把这个 Bot Token 托付给一项服务。想了解它到底经历了什么、是如何被保护的，是非常合理的问题。

当您托付 Token 时会发生什么

当您在控制台粘贴 Token 并点击 “保存” 的那一刻，内部会按以下顺序处理：

1. Token 通过 加密的通信 从浏览器发送到 BotShade 的服务器
2. 服务器端收到后，会 向 Discord 发起一次性的查询，确认 Token 是否有效，以及它对应的是哪个机器人
3. 确认通过后，Token 会 当场加密 后再保存
4. 处理结束后，明文 Token 会立即销毁

浏览器输入框中显示的 ”●●●●●●“，在保存后便无法再被还原。控制台之后展示的，仅是您本人识别 “这是我的哪个 Bot” 所需的最少信息，通常是 “最后 4 位字符” 等。

存储时如何保护

我们保管的所有 Bot Token 都 以加密状态存储。仅仅拿到存储的值，也无法从中读出 Token。

解密所需的密钥与加密后的值分开、严格地管理，能够使用它的权限也受到限制。这基于 即使一层被突破，另一层也能拦住 的纵深防御思路。

不同 Bot 之间如何隔离

BotShade 保管着许多用户的 Bot。这里最关键的是 确保 A 的 Bot 无法触及 B 的 Bot 的 Token 或数据。

Bot 的处理只能访问该 Bot 自身的数据。这种隔离并不只依赖应用程序的代码，系统层面同样加以保证。

这样做是为了尽量从机制上消除因代码缺陷或发布时的问题而 意外看到其他 Bot 数据 的余地。应用代码每天都在更新，而防护机制放在不易变化的地方会更安全。

传输过程中的防护

Token 流经的路径大致可以分为三类：

• 浏览器 ↔ BotShade 控制台
• BotShade ↔ Discord
• 内部服务之间的通信

这些通信全部经过加密。同时，我们也采取了防范可疑请求和大量访问的措施，重要的请求会在确认其来自正规来源、途中未被篡改之后再进行处理。

针对通信途中的窃听、冒充和篡改，我们分别在不同的层面同时采取了不同的对策。

谁能接触到 Token

坦白说，我们 基本上不会去接触解密后的 Token。解密路径本身没有被接入日常运维链路，因此无论是控制台开发还是客户支持工作，都不会出现需要面对明文 Token 的场景。我们不想看，也无意去看。

不过，加密状态下的字符串（ciphertext）本身，我们在运维侧出于存储完整性校验或篡改检测的目的，可能需要处理。这是为了在不解密的前提下确认 “是不是同一个值”、“有没有被破坏”，而不是用来窥探其内容。

运维上执行的管理操作，会记录是谁、在何时、做了什么。

万一出事的应对

不存在完美的防御。因此，“事情真的发生时如何处理”，我们认为同样重要。

• 可疑访问、与平常不同的登录尝试模式，都属于我们检测和复盘的对象
• 如果出现 Token 可能泄露的情况，我们会通知受影响的用户
• Token 可以通过控制台 随时重新生成，旧 Token 会被立即作废
• 安全相关的报告请发送至 help@botshade.com。我们会认真对待每一份善意的报告（详情见 负责任的披露 一节）

我们会把 Token 重新生成功能，作为 “紧急出口” 告知用户。一旦感觉哪里不对劲，第一件事就是重新生成、让旧 Token 失效——仅此一步，就能在绝大多数情况下显著遏制损害扩散。

我们刻意不做的事

一个设计的意图，不仅体现在它做了什么，也体现在它 决定不做什么 上。我们在 BotShade 中明确决定 “不做” 的事，例如下面这些：

• 不把 Token 输出到日志中：错误日志、调试日志、指标、链路追踪等，全部都不会留下 Token 本身或它的任何片段
• 不在工单或聊天中向您索要 Token：我们不会因客户支持的需要请您出示 Token。如果您收到了 “请把 Token 发给我” 这样的消息，那不会是我们
• 不在控制台之外展示 Token：无论是邮件、Discord 消息，还是任何外部服务集成，都不会让明文 Token 离开控制台界面
• 不扩散解密手段：能够使用密钥的位置与权限都限制在必要范围内，避免 “随手可得” 的状态

这些 “不做的事” 并不只是一纸政策，而是同时落到了代码与运维流程中。

我们无法覆盖的部分，以及希望您配合的事

我们坦诚地告诉您，我们能守护的范围是有边界的。下面这些情况，我们这一侧无法完全覆盖：

• 用户自己不小心把 Token 提交到了公开的代码仓库
• 控制台的登录账号被第三方接管
• 用户自己的设备被恶意软件感染

要降低后两种风险，最有效的请求是 请把控制台的入口加固起来。BotShade 的控制台采用无密码设计，您需要通过 Discord 等外部账号登录，或使用 Passkey 登录。

因此，我们希望您能配合做到以下几点：

• 为用于登录的关联账号（Discord、Google 等）启用双重身份验证 (2FA)。由于 BotShade 自身没有密码，入口的强度，直接取决于您所关联账号的强度
• 如果条件允许，请 注册 Passkey。Passkey 与设备绑定，对钓鱼攻击具有较强的抵抗力

而面对第一种风险（不小心把 Token 提交到公开仓库等），一旦察觉，请立刻前往 Discord 开发者门户，从 “Reset Token” 重新生成新的 Token。旧 Token 会当场失效。把新的 Token 重新注册到 BotShade 控制台后，您的机器人就能继续正常运行。

安全无法只靠我们一方，也无法只靠您一方独自完成。只有两侧都尽到本分，才能让设计真正收敛到 “把损害压到最小” 的状态。我们的那一份，会诚实地坚守下去。

另外，防御的具体构成以及所使用产品的名称，我们不予公开，因为这些信息可能成为攻击的线索。敬请理解。