開發者工具 · Base64 編碼器和解碼器
Base64 不是加密：為什麼任何人都可以讀取編碼的秘密
· 為什麼它很重要
base64 安全 編碼
Base64 不隱藏任何內容：任何擁有該字串的人都可以立即對其進行解碼，無需密鑰。這篇文章解釋了編碼、加密和雜湊之間的區別，以及當您在儲存庫中找到 Base64 機密時該怎麼做。
看起來被加擾並解碼為資料庫密碼的配置值 - 一個具體的發現以及它反轉的速度
在設定檔中尋找 Base64 會產生錯誤的安全感。開發人員發現一個資料庫密碼，該密碼顯示為像 dGlnZXJfZGF0YWJhc2VfYWRtaW4 這樣的加擾序列，假設它已加密，並將其與應用程式程式碼一起提交到儲存庫。幾週後，安全審查揭示了實際的明文：tiger_database_admin。
Base64 不隱藏任何內容；它是一種編碼，而不是加密。反轉後的相同密碼會立即在瀏覽器中再次變為原始密碼，無需密鑰、無需計算、無延遲。這篇文章解釋了編碼存在的原因、它與加密和雜湊的根本區別，以及當有人在提交的歷史記錄中發現 Base64 秘密時實際發生的情況。
編碼、加密和雜湊：三種不同的工作－每項保證什麼，以及哪一項需要金鑰
之所以會產生混亂，是因為 Base64 看起來像是保護。人類無法看一眼 dGlnZXJfZGF0YWJhc2VfYWRtaW4 並讀取 Tiger_database_admin。在通過解碼器執行它之前，它看起來很模糊。這種表面層面的混淆感覺像是安全的，但事實並非如此。 Base64 旨在完全解決另一個問題：透過純文字通道移動任意二進位資料。電子郵件、舊版 Web 表單和線路協定係統無法攜帶原始位元組。 Base64 將位元組轉換為可列印的 ASCII 字符，以便資料可以完整地通過這些通道。
資料到達後，接收者將其解碼回位元組。編碼和解碼同樣簡單；它們不需要金鑰，不需要熵，不需要密碼庫。編碼、加密和雜湊服務於三個不同的目的並提供三種不同的保證。編碼將資料轉換為不同的表示形式，以便它可以透過特定的通道或在特定的上下文中使用。 Base64、URL 編碼、十六進位表示，甚至 JSON 中的轉義引號都是編碼。任何人都可以逆轉它們，並不需要密鑰。
為什麼 Base64 存在－透過文字通道安全傳輸位元組，而不是機密性
目標是格式相容性，而不是機密性。相比之下，加密需要只有授權方才知道的金鑰。只有擁有正確金鑰的人才能將密文恢復為明文。如果沒有密鑰，即使對於能夠攻擊它的老練的人來說，訊息仍然是不透明的。哈希在設計上是單向的：密碼的加密哈希根本無法逆轉。它用於驗證密碼是否與儲存的雜湊值匹配，而不儲存密碼本身。
名為database-password 的 Kubernetes Secret 包含 base64: dGlnZXJfZGF0YWJhc2VfYWRtaW4 其實並不是秘密。 Base64 是 Kubernetes 用於儲存而非保護的預設編碼。任何有權存取 YAML 或 etcd 資料庫的人都可以在幾秒鐘內解碼該值。啟動腳本中具有 Base64 編碼 API 金鑰的環境變數也面臨相同的問題。向伺服器發送 Authorization: Basic base64_username:password 的 Basic Authentication 標頭可以由客戶端和伺服器之間的任何代理、監控工具或網路觀察器進行解碼。
工作範例：在瀏覽器中解碼「秘密」字串 - 貼上、解碼和純文字，不涉及伺服器
如果通道是 HTTP 而不是 HTTPS，暴露程度會更大。在這些情況下，Base64 是一種轉移注意力的方法：真正的秘密已經因以可恢復的形式儲存或傳輸而受到損害。一個有效的例子使問題變得具體。假設第三方服務的 API 金鑰在設定檔中顯示為 YXBpa2V5XzEyMzQ1Njc4OTAx。將此字串複製到瀏覽器中的 Base64 編碼器和解碼器中，將其貼上到輸入欄位中，然後按一下「解碼」。
此工具傳回 apikey_1234567890。這在您的瀏覽器中立即發生，無需聯繫伺服器，無需金鑰，也無需執行身份驗證。整個操作過程不到一秒鐘。現在假設惡意行為者在公共 GitHub 儲存庫中找到了相同的金鑰。他們可以使用他們喜歡的任何工具同樣輕鬆地對其進行解碼，並使用它來存取服務。無論字串在儲存庫中保持模糊、透過網路傳播或出現在應用程式日誌中，都可以透過每種程式語言和像這樣的瀏覽器工具中可用的簡單操作來顯示。
此錯誤出現的位置 — Kubernetes Secret、.env 檔案、基本驗證標頭和行動應用程式資源
這個錯誤隨處可見，因為 Base64 非常常見，以至於它與鄰近混淆有關。開發人員看到 Base64 編碼的資料，推斷有人認為它很重要，並以這種形式留下秘密。對於初級工程師來說，包含 API_KEY=VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 的 .env 檔案比 API_KEY= 更安全，儘管解碼需要一次操作，但這並不是真正的秘密。行動應用程式將 Base64 編碼的令牌捆綁在任何反編譯器都可以提取和解碼的資源中。資料庫備份在旨在搜尋而非保護的欄位中包含 Base64 編碼的密碼。
在每種情況下，都有人將編碼誤認為是加密，並創建了一個明文秘密檔案，而該檔案的格式恰好需要一個額外的步驟才能讀取。發現 Base64 機密後該怎麼做取決於上下文。
該怎麼做 — 秘密管理器、真正的靜態加密以及輪換任何已提交的內容
如果機密是令牌、API 金鑰或密碼，且已提交版本控制，則將其視為已洩漏。撤銷它，產生一個新的並更新它使用過的每個地方。歷史提交是儲存庫永久記錄的一部分，即使該秘密後來在新提交中被刪除；任何有權存取儲存庫歷史記錄的人都可以找到它。
在儲存庫中搜尋 Base64 編碼的值現在是一種標準的偵察策略，因此某些東西是 Base64 的事實並不意味著它是秘密的。對於任何正在進行的操作，切勿使用 Base64 對機密進行編碼並假設它們受到保護。使用秘密管理器來儲存加密、存取控制和可審計的值。在應用程式程式碼和配置中僅儲存參考或派生，而不儲存秘密本身。真正的靜態加密意味著資料使用單獨儲存的金鑰進行加密，對於沒有該金鑰的任何人來說都是無用的。
這不包括什麼 - 選擇加密演演算法或金鑰管理設計
加密敏感列的資料庫、使用硬體安全模組中的金鑰進行信封加密的秘密管理器或從使用者密碼派生加密金鑰的密碼管理器都提供真正的機密性。在秘密被儲存在任何地方之前創建的應用程式級加密更加強大。輪換已揭露的秘密，即使它們只是 Base64 編碼，也可以消除濫用的機會。如果機密位於儲存庫中，請檢查日誌以查看其被存取的時間以及在暴露視窗期間的用途。
為了持續的安全性，請使用授權服務所頒發的短期令牌，而不是儲存在配置中的靜態機密。即使受到威脅，一小時後過期的代幣對攻擊者來說價值也會降低。本文不涉及選擇加密演演算法、金鑰管理設計或驗證架構。這些都是更深層的工程問題，有自己的標準和權衡。重點更簡單：Base64 不是解決這些問題的工具之一。它是一種用於傳輸和儲存的格式轉換。
重點：將 Base64 視為明文 — Base64 編碼器和解碼器如何一鍵指出要點，而秘密永遠不會離開您的分頁
不要讓儲存庫、設定檔或日誌中出現 Base64 來安慰您資料受到保護。任何可以讀取文字的工具都可以解碼 Base64，並操作是即時且確定的。將 Base64 編碼的字串讀取為密文是一種常見的誤解，它會暴露真正的秘密。開發人員通常只有在生產或審計中發現 Base64 秘密後才意識到這一點。當工程師在本地解碼範例字串並看到原始明文立即出現時，就會出現新的視角。
此工具使這一點不可避免：編碼不是加密。一旦明確了區別，後續行動就會自動進行。程式碼庫中的每個 Base64 金鑰都必須進行輪換。每個使用秘密的地方都必須更新。必須評估暴露視窗。未來，秘密管理器和真正的加密必須取代編碼這個角色。 Base64 編碼器和解碼器準確顯示反轉的速度和容易程度，您的秘密永遠不會離開瀏覽器。將這種輕鬆視為實際的安全態勢：如果您可以在一秒鐘內解碼它，那麼其他人也可以。