秘密遮罩工具

秘密遮罩工具會掃描你即將分享的文字——記錄摘錄、支援工單、聊天訊息、設定傾印——並在其他人讀到之前移除藏在其中的憑證。把文字貼進來或把檔案拖進來，它會找出服務商 API 金鑰、存取權杖、私鑰區塊、JSON Web Token、銀行卡號和電子郵件地址，在表格中以遮罩形式列出每一處命中，並產生一份乾淨的副本，其中每個秘密都被替換為 [REDACTED]。一切都在瀏覽器中 100% 本機執行：不會上傳任何內容，不會儲存任何內容，掃描文字不會發出任何網路請求。配套指南在貼上之前先遮罩你的秘密解釋了掃描器能捕獲什麼、不能捕獲什麼；對於瀏覽器擷取，請使用 HAR 分析器；對於設定檔，請使用 .env 解析器。

最後更新:

或將文字檔拖到此框的任意位置。限制：2 MB。檔案僅在本裝置上讀取，永遠不會被上傳。

掃描器尋找什麼——以及它如何判斷

大多數秘密不是透過攻擊外洩的，而是透過熱心幫忙外洩的。有人把記錄貼進工單，把設定檔貼進聊天，把 curl 命令貼進論壇貼文——碰巧藏在裡面的憑證就隨之而去，進入那些會索引、轉發並永久封存文字的系統。本頁就是那次貼上之前的暫停。輸入或拖入文字，掃描會隨著輸入即時進行：計數條按類型彙總發現的問題，預覽在原位置醒目標示每一處命中並將其值遮罩，發現表格列出類型、遮罩形式和行號，下方的遮罩副本把每一處命中替換為統一標記 [REDACTED]，可以複製，也可以下載為 .txt 檔案。

第一層偵測靠的是形狀。真實服務商的真實憑證有可識別的形狀，掃描器認識其中主要的幾種：AWS 存取金鑰、經典與細粒度兩種形式的 GitHub 權杖、Stripe 秘密金鑰與受限金鑰、OpenAI 專案金鑰與通用金鑰、Anthropic 金鑰、Google API 金鑰和 Slack 權杖。私鑰區塊作為一個整體命中被捕獲——從它的 BEGIN 行到 END 行——因為只遮罩金鑰區塊的一部分仍然會留下一把可用的金鑰。JSON Web Token 靠其三段 base64url 結構被識別，銀行卡號必須通過 Luhn 校驗和才會被標記，這樣普通的訂單號和時間戳就不會誤報。

熵、佔位符與誠實的局限

第二層覆蓋那些沒有服務商形狀的秘密：形如 password = …、api_key: … 或 client_secret = … 的賦值。一個光禿禿的關鍵字什麼也證明不了，所以值必須再過兩道門——至少十二個字元，以及每字元至少 3.2 位元的夏農熵，隨機金鑰很容易通過，普通單詞則會失敗。佔位符值按設計被排除：任何包含 example、test、dummy、xxx、your-、placeholder 或 changeme 的內容都是文件，而不是憑證，標記它只會訓練你無視掃描器。當形狀重疊時，具體的模式勝出：被賦值給變數的 Stripe 金鑰只報告一次，類型就是 Stripe 金鑰。

有兩種發現保護的是人，而不是系統。電子郵件地址被標記為個人資料，因為一整張寫滿客戶地址的工單即使沒有出現任何密碼，也是一次隱私事件。銀行卡號只在數字通過 Luhn 時才標記，Luhn 是每一張真實銀行卡號內建的校驗和——正是這個檢驗讓掃描器可以忽略那些只是看起來又長又有數字的發票號、追蹤代碼和 Unix 時間戳。在畫面上，每個值最多遮罩到只顯示前四個字元，因此偷看畫面的人或一張截圖只能知道秘密的類型和位置，永遠學不到秘密本身；短值則什麼都不顯示。完整的值只存在於你的原始文字中，而它從不離開本頁。

請把遮罩工具當作一種更安全的分享習慣中的一步，而不是一種保證。在本機遮罩，分享遮罩副本，而當秘密確實必須交到他人手中時，透過秘密管理器或過期的分享連結傳送真正的秘密——永遠不要與遮罩文字走同一張工單或同一個聊天。如果某個真實憑證已經被未遮罩地貼到了某處，刪除那條訊息是不夠的：副本、索引和通知可能已經存在，因此請輪換該憑證，並把舊的當作已經公開。配套文章在貼上之前先遮罩你的秘密完整地介紹了這一流程；HAR 分析器為瀏覽器擷取做同樣的事情，.env 解析器則在你提交設定檔之前檢查它們。

用通俗的話說明偵測庫

AWS 存取金鑰AKIA 或 ASIA 後跟恰好 16 個大寫字母或數字——長期與臨時 AWS 存取金鑰 ID 的形狀。
GitHub 權杖ghp_、gho_、ghu_、ghs_ 和 ghr_ 前綴再加至少 36 個字元，以及細粒度的 github_pat_ 形式。
Stripe 金鑰sk_ 或 rk_ 後跟 live_ 或 test_ 以及至少 16 個字母數字字元——秘密金鑰與受限金鑰，測試模式也包括在內，因為測試金鑰會暴露帳戶結構與習慣。
OpenAI 與 Anthropic 金鑰sk-proj- 專案金鑰和 32 個字元以上的通用 sk- 金鑰計為 OpenAI；sk-ant- 金鑰報告為 Anthropic——一種單獨的類型，一條單獨的輪換路徑。
Google API 金鑰與 Slack 權杖Google 是 AIza 後跟 35 個字元；Slack 是 xoxb、xoxa、xoxp、xoxr 和 xoxs 前綴，分別對應機器人、應用、使用者、重新整理和工作階段權杖。
私鑰區塊一整塊 PEM，從 -----BEGIN PRIVATE KEY-----（包括 RSA、EC、OpenSSH 和 PGP 變體）到對應的 END 行，作為一處命中報告和遮罩。
JSON Web Token由點分隔的三段 base64url，前兩段以 eyJ 開頭——每個 JWT 都以這種 JSON 標頭與承載的編碼形式開頭。
通用賦值賦值給 api_key、secret、token、password、passwd、auth_token、access_token 或 client_secret 等名稱的值，僅當值至少 12 個字元且夏農熵達到 3.2 時才標記；文件佔位符從不標記。
電子郵件地址普通的電子郵件地址，作為個人資料（PII）報告，使客戶或員工地址的大量貼上在擴散之前被抓住。
銀行卡號13 到 19 位的數字序列，允許空格和連字號，僅當通過每張真實卡都滿足的 Luhn 校驗和時才標記。
遮罩與標記在畫面上，一個值最多顯示前四個字元加省略號，四個字元或更短的值什麼都不顯示。在遮罩副本中，每處命中都變成統一標記 [REDACTED]；類型在發現表格中可見，從不內嵌顯示。

常見問題

我的文字會被上傳或儲存到任何地方嗎？

不會。掃描在本頁、你的裝置上執行：任何內容都不會被上傳、傳輸或儲存，掃描不會發出任何網路請求。這是一條刻意的設計規則——一個要求你先上傳滿是秘密的文字再來移除秘密的工具，本身就是問題的一部分。

它能找到哪些種類的秘密？

服務商形狀的憑證——AWS 存取金鑰，以及 GitHub、Stripe、OpenAI、Anthropic、Google 和 Slack 的金鑰與權杖——加上完整的私鑰區塊、JSON Web Token、賦值給 password 或 api_key 等名稱的高熵值、電子郵件地址，以及通過 Luhn 校驗和的銀行卡號。上面的事實表用通俗的話列出了每一種模式。

為什麼它漏掉了我能在文字中看到的秘密？

有三個誠實的原因。值可能被拆到多行或被折行，因此沒有單一形狀能匹配。它可能是一個低熵的人類口令，被賦值給通用規則不認識的名稱。或者它可能是一種尚無模式覆蓋的格式——資料庫連接字串、Cookie 值、基本驗證 URL。掃描器以確定性的方式捕獲那些常見、文件齊全的形狀；它是一張安全網，而不是文字已經乾淨的證明，所以在分享之前請自己快速瀏覽一遍預覽。

為什麼它標記了並不是真正秘密的東西？

通常是因為那個值確實長得像秘密：一個沒有佔位符措辭的、看起來很隨機的測試值、內部文件中的範例權杖，或被用作前端範例的 JWT。分享之前先看一眼發現表格——一次誤報只花一眼，而一次漏報要花一次輪換。包含 example、test、dummy、xxx、your-、placeholder 或 changeme 的值從不被標記，因此把樣本這樣標明可以減少雜訊。

如果原文已經外洩，遮罩能讓秘密安全嗎？

不能。遮罩保護的是你從現在起製作的副本；它無法召回一份已經帶著秘密發出的工單、聊天訊息或記錄。把任何曾經未遮罩地出現在共享系統中的憑證當作公開的：在服務商處輪換它、吊銷舊的，然後才分享遮罩後的文字。配套文章在貼上之前先遮罩你的秘密解釋了先輪換的順序，以及為什麼僅僅刪除訊息是不夠的。