線上雜湊產生器:MD5、SHA-1、SHA-256 和 SHA-512 合而為一

我的 WP Adminify 時代最糟糕的支援之夜是從白色螢幕開始的。我們'd 於晚上 11 點左右將版本 3.1。2 推送到更新伺服器,到凌晨 2:40 我收到了 14 張門票,上面寫著同樣的話:安裝了更新,網站已死。我回滾,重新測試了機器上的拉鍊 - 運作完美。相同的版本。相同的文件。據說。

我花了很長時間才做了一件顯而易見的事情:對兩個文件進行哈希處理。這 SHA-256 我的筆記型電腦上的 zip 和更新伺服器上的 SHA-256 的 zip 沒有 #39;匹配。甚至還沒有接近 - 完全不同的摘要。上傳在傳輸中期的某個地方被截斷,伺服器很高興地提供了損壞的存檔,並且 PHP 堵塞了內部不完整的文件。在更新之前,一個校驗和比較就會捕獲它。那天晚上之後,每個 WP Adminify 版本都會在部署日誌中列印其 SHA-256,並且上傳腳本拒絕發布,除非遠端雜湊與本地雜湊相符。此後零損壞版本。

那'哈希是什麼,最實用的是:資料指紋。輸入檔案或字串,返回一個短的固定長度摘要。如果甚至一個位元組發生變化 - 翻轉位元、截斷下載、偷偷編輯 - 摘要也會完全改變。我現在每週多次在線訪問哈希生成器:驗證下載、調試 Webhook 簽名、跨環境比較配置文件、理智檢查兩個 "相同&引用;文件實際上是。

這就是為什麼我建造了一個 工具。dev. 我想要一個雜湊工具,可以計算瀏覽器中的所有內容,並排向我顯示 MD5、SHA-1、SHA-256 和 SHA-512,並且永遠不會在任何地方上傳我的輸入的位元組。本指南涵蓋如何使用它、什麼'這實際上發生在幕後,以及我早期在雜湊方面犯的一個錯誤 - 今天我仍然在程式碼庫中看到。

TL;DR: 使用 toolz。dev 哈希產生器 要計算 MD5、SHA-1、SHA-256 和 SHA-512,請立即完全透過 Web Crypto API 在瀏覽器中從文字或檔案中消化。對於任何重要的事情,預設為 SHA-256;僅將 MD5 和 SHA-1 視為舊校驗和。並且永遠不要將這些中的任何一個用作密碼。 That' bcrypt 或 Argon2 領土。

主要特點

一次使用多種演算法

貼上一次輸入,同時計算 MD5、SHA-1、SHA-256 和 SHA-512。這聽起來有點方便,直到你'重新調試別人'系統,你不知道他們使用了哪種演算法。 I'我為此失去了即時時間 - 支付網關'文件說&引用;SHA哈希引用;沒有附加號碼,我坐在那裡一次在終端中生成一個演算法,直到匹配為止。當所有四個摘要同時出現在螢幕上時,您只需眼球即可看到與您' 嘗試匹配。它也使差異變得發自內心:您可以在 128 個字元的 SHA-512 旁邊看到 32 個字元的 MD5,並立即了解 "摘要大小&引用;意味著在實踐中。

文字和檔案哈希

鍵入或貼上字串,或放入檔案 - 該工具可以處理這兩種情況。文字雜湊涵蓋了日常情況:API 簽章偵錯、快取金鑰、快速比較。檔案雜湊是真正驗證工作發生的地方。根據已發布的校驗和檢查下載的安裝程序,確認插件 zip 在更新伺服器上保存下來,驗證在機器之間完整複製的資料庫轉儲。該檔案永遠不會上傳到任何地方;它'透過瀏覽器本地讀取並散列到位。 I'以這種方式散列了數百兆位元組的 SQL 轉儲。 It'比你快'預計,因為繁重的工作發生在本機瀏覽器程式碼中,而不是 JavaScript 循環中。

透過 Web 加密進行即時客戶端計算

SHA 系列摘要使用瀏覽器計算'內建 Web 加密 API - crypto.subtle.digest- 它運行瀏覽器附帶的本機、優化的加密程式碼。沒有伺服器往返,沒有隊列,沒有旋轉器。您獲得結果的速度與您的機器讀取輸入的速度一樣快。這很重要有兩個原因。首先,速度:雜湊發生在毫秒內,即使對於大輸入也是如此。其次,信任:由於計算是本地的,因此無論您'在咖啡店上網或在鎖定的網路上雜湊敏感配置,該工具的工作原理都是相同的。頁面加載一次;之後,網路就無關緊要了。

大寫和小寫輸出

瑣碎的功能,可以避免真正的頭痛。十六進位摘要的含義不區分大小寫 - 2CF24DBA 和 2cf24dba 對相同的位元組進行編碼 - 但字串比較 don'不知道。許多系統以大寫形式儲存或發布摘要(某些 Windows 工具、某些供應商校驗和頁面),而大多數 Unix 工具則發出小寫。如果您'將摘要貼上到比較腳本或設定檔中進行精確的字串匹配,則大小寫突然變得非常重要。切換意味著您複製所需的格式,而不是透過大小寫轉換器運行輸出,或者更糟的是,"fixing"它是透過手和胖手指撫摸一個角色。

比較和驗證模式

散列只是工作的一半 - 通常是 you'根據期望值檢查摘要。將已發布的校驗和貼到您計算的校驗和旁邊,工具會立即告訴您它們是否匹配,不需要瞇著眼睛看 64 個十六進位字元。我曾經透過直觀地比較前幾個字元來驗證校驗和。 That'這正是您錯過中間不匹配的情況。人眼在比較長隨機字串方面很糟糕;那'這是一項平等檢查的工作。驗證模式還可以標準化情況並在比較之前修剪空白,從而消除最常見的誤報:草率的複製貼上造成的雜散尾隨空間。

100% 私密 - 沒有什麼可以離開您的瀏覽器

這是我拒絕在所有 toolz。dev 上妥協的功能。您的輸入 - 文字或檔案 - 在本地被散列並且從未傳輸。那裡'沒有伺服器端處理,沒有日誌記錄,沒有"我們匿名化您的資料&報價;列印,因為那裡'沒有資料可記錄。這對雜湊來說比人們意識到的更重要:開發人員雜湊的東西通常正是他們應該的東西'在調試 HMAC 簽名、許可證密鑰、轉儲客戶電子郵件時使用的 API 秘密。使用客戶端工具,風險就會消失。打開您的瀏覽器'如果您想要證明,則會在雜湊時顯示網路標籤。我寫了更多關於為什麼這個架構在我的作品中很重要的文章 資料隱私和線上工具 貼文。

如何使用哈希產生器

第 1 步:開啟工具並選擇輸入

前往 哈希產生器. 你'將看到一個輸入區域,接受鍵入/貼上文字或檔案。對於文本,只需開始輸入 - 雜湊處理就在您進行時發生。對於文件,將文件拖曳到下拉區或使用文件拾取器。沒有上傳任何內容;該文件由您的瀏覽器在本地讀取。那裡'沒有超出您的機器的大小上限'記憶體很舒服。

第二步:閱讀文摘

所有演算法同時計算:MD5、SHA-1、SHA-256、SHA-512。每個摘要都出現在自己的標記行中,十六進位。注意長度 - MD5 為 32 個字符,SHA-1 為 40 個字符,SHA-256 為 64 個字符,SHA-512 為 128 個字符。如果您'與已知的校驗和相匹配,並且 you'不確定是哪種演算法產生的,在比較單一字元之前,通常會先告訴您長度。

步驟 3:如果需要,請切換案例

如果系統是you'與使用大寫十六進位進行匹配,請翻轉大小寫切換。摘要位元組無論哪種方式都是相同的 - 這純粹是關於字串格式。使用複製按鈕複製摘要而不是手動選擇; 128 個字元的 SHA-512 摘要非常容易部分選擇,並且截斷的摘要將默默地失敗您與它進行的每次比較。

步驟 4:根據預期雜湊值進行驗證

從供應商獲得已發布的校驗和'下載頁面或同事'部署日誌?將其貼到比較欄位中。該工具會根據您計算的摘要進行檢查,並給出明確的匹配或不匹配。匹配意味著資料逐字節與產生原始雜湊值的資料相同。不匹配意味著某些內容發生了變化 - 傳輸損壞、文件版本錯誤或篡改。 Don't 合理化不匹配。重新下載並再次檢查。

MD5 vs SHA-256:What's 實際上發生在引擎蓋下

加密雜湊函數接受任意長度的輸入並產生稱為摘要的固定長度輸出。四個屬性使其有用。它's 確定性- 相同的輸入總是產生相同的摘要。它展示了 雪崩效應- 更改一位輸入並翻轉大約一半的輸出位元。它's 單向- 那裡'沒有從摘要返回輸入的可行路徑。和#39;s 抗碰撞- 尋找產生相同摘要的兩個不同輸入在計算上應該是不可行的。

雪崩效應值得真實價值看到。 MD5 的 hello 是 5d41402abc4b2a76b9719d911017c592. 將一個字母大寫 - Hello- 你得到了 8b1a9953c4611296a827abf8c47804d7. 沒有一個角色改變;完全不相關的摘要。與 SHA-256 的故事相同: hello 哈希到 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824,同時 Hello 產生的摘要與它基本上沒有任何共同點。那'是重點。摘要告訴你 無論 數據從未改變 多少.

現在,演算法。 MD5 早在 1992 年就在 RFC 1321 中進行了定義,並產生了 128 位元摘要。它'速度快,它'到處都是 - 並且它'密碼破解。自 2004 年以來,實際衝突攻擊就已存在;研究人員可以在商品硬體上使用相同的 MD5 摘要製造兩個不同的輸入。這可以殺死任何對抗性的東西:攻擊者可能替換內容的簽名、憑證、完整性檢查。對於非對抗性校驗和來說仍然很好 - 檢測文件傳輸中的意外損壞,重複使用您自己的資料 - 因為隨機損壞不會't 選擇其位元組。 SHA-1 (160 位元)持續時間更長,但 SHAttered 攻擊在 2017 年表現出實際衝突,兩個不同的 PDF 共享一個 SHA-1 摘要。由於歷史原因,Git 仍然在內部使用 SHA-1,但沒有新系統應該這樣做。

的 SHA-2家族- 其中 SHA-256 和 SHA-512 - 在 FIPS 180-4 中指定且未損壞。 SHA-256 為您提供 256 位元摘要,並且是幾乎所有內容的正常預設值。 SHA-512 提供更大的摘要,並且經常如此 更快 在 64 位元 CPU 上,因為它適用於 64 位元字。

人們不斷模糊的三個差異。 哈希 是單向的--沒有鑰匙,沒有回頭路。 加密 是雙向的 - 任何擁有密鑰的人都可以解密。 編碼,就像 Base64 一樣,是零路保護 - it'只是表示更改,任何人都可以反轉,不需要金鑰。如果您'曾經見過 Base64 被視為 "加密,"我的 Base64 轉換器 將愉快地證明為什麼會這樣'是一個問題,我的 Base64 編碼指南 涵蓋了深度上的區別。

當您需要證明訊息來自持有共享秘密的人時 - webhook 簽名、API 請求簽名 - 普通哈希值是 't 足夠了,因為任何人都可以哈希。那's HMAC,在 RFC 2104 中定義:一種鍵控結構,它包裝雜湊函數,因此只有鍵持有者才能產生有效的摘要。 HMAC-SHA256 是大多數 Webhook 簽章方案背後的主力,you'將永遠調試。

還有一個大的: 切勿使用快速雜湊值對密碼進行雜湊處理。 快速是這裡的敵人 - 資料庫洩漏的攻擊者可以在 GPU 上每秒測試數十億個 MD5 或 SHA-256 猜測。密碼需要故意緩慢、加鹽的演算法:bcrypt 或 Argon2。拉拉維爾's Hash::make() 正是出於這個原因,預設使用 bcrypt,而 WordPress 在現代化之前花了數年時間開發 phpass 便攜式哈希方案 - 不完美,但本能(放慢速度,加鹽)是正確的。我透過艱苦的方式了解到了這一點:我的一個早期自由職業項目,比 WP Adminify 早幾年,將密碼儲存為原始密碼 md5($password). 經典新秀動作。沒有人被突破,但我仍然畏縮。

這裡'是 toolz。dev 工具在幕後做什麼,以及你'自己寫什麼:

const data = new TextEncoder().encode('hello');
const buf = await crypto.subtle.digest('SHA-256', data);
const hex = [...new Uint8Array(buf)]
  .map(b => b.toString(16).padStart(2, '0'))
  .join('');
// "2cf24dba5fb0a30e26e83b2ac5b9e29e..."

或在 PHP 中,一行: hash('sha256', 'hello'). 相同的輸入,相同的摘要,任何語言,任何機器。決定論是整個基礎。

常見用例

驗證文件下載並發布工件

在介紹中讓我著迷的用例。供應商在下載旁邊發布校驗和的原因有:傳輸損壞、鏡像過時,偶爾有人惡意交換文件。下載文件,用哈希 哈希產生器,與已發布的值進行比較。匹配:該文件與發布者散列的內容位元組相同。不匹配:停止並重新下載。對於我自己的版本,自凌晨 2:40 事件以來的規則是機械的 - 部署腳本在本地計算 SHA-256,上傳,獲取遠端檔案'哈希值,並拒絕翻轉 "當前版本"指針,除非它們'相等。 It'可能有八行狂歡。此後它捕獲了兩次被截斷的上傳,這兩次都將是門票氾濫。我整個管道中最便宜的保險。

快取破壞和 ETag

瀏覽器積極緩存,並且"請硬刷新和引用;不是一種部署策略。穩健的修復是內容雜湊的檔案名稱:雜湊檔案'內容並將摘要的一部分嵌入到名稱中,所以 app.css 成為 app.2cf24dba.css. 內容變更、雜湊變更、檔案名稱變更、快取未命中、使用者取得新檔案。內容相同、檔案名稱相同、快取命中。 Laravel Mix 和 Vite 會自動執行此操作;在 WP Adminify 中,我做了一個本土版本,對資產內容進行雜湊處理來建立 ver 查詢字串 WordPress 附加到排隊腳本 - 在太多 &quot 之後;設定面板看起來破解了"門票確實陳舊 CSS。相同的原理為 ETags 提供支援:伺服器雜湊回應,瀏覽器將雜湊傳回,匹配意味著微小的 304 而不是完整的有效負載。

重複資料刪除的內容

想知道兩個檔案是否相同,而不逐字比較它們 - 或者它們何時生活在不同的機器上?哈希兩者。相同的摘要意味著相同的內容(對於 SHA-256,衝突幾率小得離譜,它們'不值得思考)。這非常美妙:哈希一千次上傳,對摘要進行排序,並立即複製簇。 I'用它來推導一個累積了多年的 WordPress 媒體庫 logo.png, logo-1.png, 和 logo-final-2.png- 哈希揭示了哪些實際上是相同的圖像,但名稱不同。 It'還有備份工具如何決定跳過什麼以及如何偵測物件儲存偵測到 "上傳&引用;是他們已經持有的內容。

Git 風格的內容尋址

Git 沒有't 按名稱儲存檔案 - 它按雜湊值儲存檔案。每個 blob、樹和提交都透過其內容摘要來解決(歷史上是 SHA-1,SHA-256 轉換正在進行中)。 That'為什麼提交 ID 看起來像雜湊值:它們 是 哈希,它們涵蓋了快照、父母、作者、時間戳記。更改歷史記錄中的任何位置,每個下游哈希都會發生變化,這使得篡改 Git 歷史記錄變得非常明顯,而不是悄悄地成為可能。了解這一點改變了我調試 Git 問題的方式。當兩台機器對提交有分歧時,比較哈希會立即告訴您是 you'正在查看相同的物件還是不同的歷史記錄。內容尋址是聽起來學術的想法之一,直到它保存您的回購。

在不暴露秘密的情況下比較配置

舞台作品、製作不't,你懷疑 .env 文件不同 - 但你不'不希望生產秘密貼到 Slack 線程或螢幕共享中。在自己的機器上對每個文件進行哈希並比較摘要。不同的哈希值可以確認文件的不同,但不會顯示單一值。您可以做得更精細:對各個行或特定鍵進行哈希以精確定位 哪個 條目存在分歧。我'以這種方式解決了託管支援的分歧 - "你的配置副本與我的配置不匹配,這裡'我的 SHA-256,檢查你的和報價;在一則訊息中結束辯論。摘要證明了差異或相同性,而秘密則準確地保留在它們所屬的地方。

網路掛鉤簽名調試

Stripe、GitHub、Paddle - 它們都會簽署 Webhook 有效負載,通常使用 HMAC-SHA256,因此您可以驗證請求實際上來自它們。當您的驗證失敗時,調試會很糟糕,因為失敗是無聲的:簽名只是 don't 匹配,中間件說不。十分之九的罪魁禍首是有效負載 - 您的框架重新序列化了 JSON,更改了空格或密鑰順序,因此 you'重新雜湊出與已簽署不同的位元組。哈希 生的 在管道中的各個點請求正文會向您顯示位元組突變的確切位置。如果摘要在路由處理程序和驗證函數之間發生變化,您've 找到了 's 接觸身體的層。而你'就在那個街區,我的 中國航空解碼器 對於檢查簽名代幣的相鄰工作來說很方便。

MD5 vs SHA-1 vs SHA-256 vs SHA-512:您應該使用哪一個?

我的立場,以及 I'會直言不諱的: 預設為 SHA-256 並停止考慮它。 它'安全、普遍支援、足夠快,您永遠不會注意到成本,它'這是您的工具已經講過的內容 - TLS 憑證、Docker 映像摘要、套件鎖定檔案、webhook 簽章。選擇演算法所花費的精神能量幾乎總是最好花在其他地方。

值得保留的細微差別:MD5 是't 放射性,它's 有範圍. 偵測到您自己的檔案意外損壞?美好的。人類對手可以從偽造衝突中受益嗎?絕對不是。 SHA-1 坐在同一個桶中,藉口更少 - 觸摸它的唯一充分理由是與您所擁有的系統的兼容性't 控制。 SHA-512 是一個不錯的選擇,在現代 64 位元硬體上偶爾會更快,但 128 個字元的摘要在日誌和 URL 中很笨拙,而且 SHA-256 的安全裕度已經超出了任何現實攻擊的範圍。這四個--重複,沒有--都不屬於密碼欄位附近的任何位置。

常見問題

MD5 還可以安全使用嗎?

為了安全起見,沒有。自 2004 年以來,實際衝突攻擊就已存在,這意味著攻擊者可以使用相同的 MD5 摘要製作兩個不同的檔案。切勿將其用於簽名、憑證、密碼儲存或任何涉及篡改的完整性檢查。對於非對抗性工作(偵測意外損壞、重複資料刪除自己的檔案、產生快取金鑰),沒有人試圖愚弄您,它仍然是可以接受的。如有疑問,請使用 SHA-256;它不會花費您任何費用。

可以反轉雜湊值來取得原始資料嗎?

沒有哈希函數在設計上是單向的 - 摘要包含的資訊比大多數輸入少得多,因此一般來說,反轉在數學上是不可能的。攻擊者實際上所做的是猜測:使用彩虹表或 GPU 暴力對數十億個候選輸入進行哈希並比較摘要。這對於快速演算法中的密碼雜湊等短而常見的輸入效果非常好,這正是密碼需要緩慢、鹽醃的雜湊而不是普通的 MD5 或 SHA-256 的原因。

哈希和加密有什麼區別?

加密是雙向的:資料是用金鑰加擾的,任何持有正確金鑰的人都可以將其解密回原始資料。雜湊是單向的:您可以根據資料計算摘要,但無法從摘要中恢復資料 - 沒有金鑰,也沒有解密。當您需要返回資料時使用加密,當您只需要驗證或比較時使用雜湊。 Base64,作為記錄,兩者都不是 - 它是編碼,任何人都可以反轉。

我應該使用哪個雜湊值來表示密碼?

該工具中沒有一個。 MD5、SHA-1、SHA-256 和 SHA-512 都很快,而且快速對於密碼來說是致命的 - GPU 可以根據洩漏的資料庫每秒測試數十億次猜測。使用故意緩慢的鹽醃演算法:bcrypt 或 Argon2。 Laravel's Hash::make() 預設使用 bcrypt,大多數現代框架都提供等效的。如果您正在編寫原始雜湊呼叫以進行密碼存儲,請停止並存取您的框架'而是密碼雜湊 API。

在線上工具中散列敏感資料安全嗎?

僅當該工具真正是客戶端時才可以。 toolz。dev Hash Generator 使用 Web Crypto API 計算瀏覽器中的每個摘要 - 您的輸入永遠不會傳輸、記錄或儲存在任何伺服器上。您可以透過在雜湊時查看網路標籤來自行確認這一點。使用伺服器端工具,您可以信任未知操作員,無論您貼上什麼,這對 API 機密、金鑰或客戶資料來說都是一個糟糕的交易。如有疑問,請在貼上之前檢查。

為什麼要"你好&引用;和&引用;你好&引用;產生完全不同的哈希值?

這就是雪崩效應,而且是故意的。當即使一個輸入位元發生變化時,一個好的雜湊函數也會翻轉大約一半的輸出位,因此相似的輸入會產生截然不同的摘要。大寫一個字母會改變一個字節,但摘要變得無法辨識。這是一個功能:這意味著摘要不會顯示兩個輸入的相似程度,並且當您比較雜湊值時,任何更改(無論多麼微小)都不可能錯過。

SHA-256和SHA-512有什麼不同?

兩者都屬於 FIPS 180-4 中指定的 SHA-2 系列,並且都被認為是安全的。 SHA-256 使用 32 位元操作產生 256 位元摘要; SHA-512 使用 64 位元操作產生 512 位元摘要,這通常使其在現代 64 位元處理器上更快。實際上,SHA-256 是生態系統預設值,其摘要長度只有一半,這使得日誌和 URL 可以管理。選擇 SHA-512 以獲得額外的安全裕度或 64 位元吞吐量;否則 SHA-256 就足夠了。

我什麼時候需要 HMAC 而不是普通雜湊值?

每當您需要證明誰產生了哈希值時,請使用 HMAC,而不僅僅是哈希值。任何人都可以計算簡單的摘要,因此它驗證完整性,但不能驗證來源。 RFC 2104 中定義的 HMAC 將金鑰混合到雜湊過程中 - 只有持有金鑰的各方才能產生或驗證有效簽章。這是來自 Stripe、GitHub 和類似服務的 Webhook 簽章背後的機制,幾乎總是與原始請求正文上的 HMAC-SHA256 一樣。

帶著指紋的船,而不是信仰

雜湊是罕見的工具'既是深層計算機科學,也是極其簡單的日常練習。你不知道'需要了解 MerkleeovDamgadh 的結構才能從中受益 - 你需要這個習慣。哈希您的發布工件。驗證您的下載。比較摘要而不是眼球文件。這些習慣中的每一個都是三十秒的工作時間,每一個習慣都在某個時候為我節省了一個晚上,否則我會在支援隊列中道歉。

的 toolz。dev 哈希產生器 旨在使這種習慣無摩擦:四種演算法同時進行,文字和文件,驗證模式,全部在瀏覽器中計算,沒有上傳任何內容。如果您'正在研究相鄰的概念, Base64 轉換器 涵蓋編碼(以及為什麼它是't安全),the 密碼產生器 處理您永遠不應該使用 SHA-256 散列的秘密,以及 中國航空解碼器 故事的簽名部分更加圓滿。

為了更大的圖景,我的 編碼工具指南 瀏覽開發人員工具箱的其餘部分,以及 線上工具中的資料隱私 解釋了為什麼客戶端處理是山 I'選擇死。哈希第一,部署第二。凌晨 2:40 的自己會感謝你的。