為什麼 3Commas 被偷 $22M
而 TVSBot 的設計不會
2022 年 12 月，加密自動交易最大品牌 3Commas 發生史上最嚴重的 API key 外洩 — 100 萬把交易所 key 託管在他們資料庫，外洩 10 萬把，鏈上分析師 ZachXBT 驗證 44 名受害者損失 $14.8M，總被盜估計 $22M。
這不是「他們被駭」的故事，是「託管模型的單點失靈」的故事。本文拆解事件、 解釋為什麼這種設計遲早會出事、以及 TVSBot 怎麼避開。
第一幕：事件時間線
2022 年 10-11 月：用戶開始回報「我沒下單，但帳戶在 FTX (FTT) 自動交易」。3Commas 初始回應是「用戶自己 phishing」。
2022 年 12 月 28 日：駭客在 Twitter 公開部分 API key 檔案，附帶下載連結。經 ZachXBT 與獨立研究員交叉驗證，這些 key 對應的 帳戶確實有發生未授權交易。
12 月 29 日：3Commas CEO Yuriy Sorokin 承認事件， 並請求 Binance、OKX、KuCoin 等交易所配合「revoke 所有 3Commas 託管的 API key」。這個請求本身揭露了一個關鍵事實 — 3Commas 無法自行修復用戶資金損失，因為 key 屬於別人的平台， 他們只能請求別人撤銷。
第二幕：技術根因
託管型 bot 平台的標準架構長這樣：
用戶 → bot 平台
├── 加密儲存 API key + secret（資料庫）
├── 解密後呼叫交易所 API 下單
└── 結果回報給用戶這看起來合理 — key 加密了嘛。但這個設計有一個 共同失靈點（single point of failure）：資料庫 + 解密金鑰，是 100 萬個用戶的單一信任端。
一旦資料庫被 dump（無論透過 SQLi、雲端配置錯誤、內部人員 leak）， 加上解密金鑰也外洩（多數平台金鑰跟 DB 在同個雲環境）， 所有用戶 key 同時暴露。
這就是 3Commas 發生的事：根據事件報告，金鑰管理跟 DB 在同一個雲服務內， 一次入侵全部攻陷。
更糟的是：託管的 key 通常有 Trade + Withdraw 權限
很多 bot 平台為了「方便用戶開啟更多策略類型」（自動轉倉、跨幣套利等）， 建議用戶把 Withdraw 權限也勾起來。3Commas 部分受害用戶就是這種狀態 — 攻擊者直接從交易所提幣到自己錢包。
第三幕：TVSBot 的架構為什麼不同
我們從第一天就為避開這個失靈模式而設計，具體 3 條：
1. 強制 Order-only 權限（最關鍵）
系統每天掃所有 active API key，呼叫交易所 API 確認權限。任何帶有 Withdraw 旗標的 key 自動停用，並 TG 通知用戶。
這代表：即使 key 被偷，攻擊者也無法提幣。最壞情況是 wash trade 損失少量手續費，資金鎖在交易所帳戶。
2. 加密金鑰跟 DB 物理分離
DB 在 Supabase（一個雲廠商），FERNET_MASTER_KEY 存在 Fly secrets（不同雲廠商）。攻擊者要同時打穿兩個獨立的雲環境才能解密 key — 這比打穿單一服務難太多。
金鑰也不會進 git、不會進 DB backup、不會存任何 log。連我們自己 admin 直查 DB 也只能看到 base64 加密字串。
3. IP 白名單建議
各交易所 API 都支援 IP 白名單。我們文件直接列 TVSBot Fly 的 egress IP， 建議用戶設成白名單。設了之後就算 key 完全外洩，沒在白名單也呼叫不了。
4. 訊號雙重驗證
每個用戶的 webhook URL 帶獨立 token，payload 內另帶 secret 雙重驗證。 一個外洩無法繞過另一個 — 攻擊者要同時偷到 URL token 和 secret 才能偽造訊號。
第四幕：「但你也是託管啊」— 觀念釐清
有人會說：「TVSBot 不也是託管 API key 嗎？跟 3Commas 一樣的設計？」
技術上 key 確實在我們 DB 裡。但實質上差異巨大：
| 面向 | TVSBot | 3Commas（事件當時） |
|---|---|---|
| 提幣風險 | 0（系統自動停用） | 有，部分用戶開了 Withdraw |
| 加密金鑰位置 | 不同雲廠商 | 同雲環境 |
| 加密演算法公開 | ✓ Fernet AES-128-CBC | 未公開實作細節 |
| Bug bounty | ✓（見 /security） | 當時無 |
| 事件揭露時效承諾 | 72 小時內 | 事件後 2 個月才承認 |
第五幕：你能做的事
無論用 TVSBot 或任何 bot 平台，以下 3 件都是你的責任，沒人能代勞：
- 不要勾 Withdraw 權限 — 這是最重要的一條，比所有 技術設計都重要
- 設 IP 白名單 — TVSBot dashboard 會列出我們的 egress IP
- 定期輪換 key — 至少每 3 個月，更短更好
結語：信任不是免費的
3Commas 事件後，加密 bot 行業普遍意識到「託管模型」是核心問題。 有些平台轉向「pure non-custodial」（瀏覽器擴充、本地代理）， 有些加強加密設計（HSM、多重簽名）。
我們的選擇是「實用主義 non-custodial」： 技術上託管但結構上保證資金安全（強制 Order-only + 加密金鑰物理分離 + 多層驗證）。
我們認為這個 trade-off 在使用體驗（用戶不用裝 extension）跟安全保證 之間取得最佳平衡。但每個人風險偏好不同 — 如果你要絕對 non-custodial， 也理解。
有任何安全建議或漏洞回報，請寄到 security@tvsbot.com。Bug bounty 詳情見 /security 頁。