HMAC 與一般雜湊有什麼差別?

一般雜湊對任何輸入都具有確定性——任何人都能算出。HMAC 則加入了密鑰,只有持有金鑰的雙方才能產生相符的簽章。這也是 HMAC 適合做驗證、而一般雜湊只能做完整性檢查的原因。

我該選哪一種演算法?

除非整合的服務明確要求別的,否則就用 HMAC-SHA256。SHA-1 在舊系統中仍常見,但不適合用於新設計。SHA-512 在多數情境下其實過頭了,但相對更保守。

金鑰應該是字串還是位元組?

HMAC 接收的是位元組序列。Toova 預設把您的金鑰當作 UTF-8 文字處理,與大多數 API 的作法一致。如果規格寫的是「hex-encoded secret」,請切換金鑰編碼,使位元組與服務期望的相符。

我的密鑰會被送到伺服器嗎?

不會。簽章完全在您的瀏覽器中執行。密鑰與訊息從不離開裝置,簽章期間 Network 分頁會保持空白。

為什麼我的簽章與服務期望不一致?

最常見的原因:編碼不一致(十六進位 vs Base64)、payload 末尾有換行,或演算法錯誤。請逐一比對服務文件確認三者都吻合。

HMAC 產生器 — 線上 HMAC-SHA-256 與 SHA-512

HMAC 產生器 (SHA-256、SHA-512)

注重隱私的設計 — 完全在您的瀏覽器中執行

在瀏覽器中,從訊息與密鑰產生 HMAC-SHA256(或 SHA-1、SHA-512)簽章。Toova 是簽署 webhook payload、API 請求,以及任何需要雙方共用密鑰並驗證真實性的流程的理想工具。

HMAC 的用途

HMAC 會把共用密鑰與訊息合成一個固定長度的簽章。接收端如果也知道密鑰,就能重新計算 HMAC 並逐位元組比對——若簽章相符,代表訊息真實且未被竄改。Stripe、GitHub、Slack 以及幾乎所有 webhook 系統都使用 HMAC-SHA256 簽署 payload,讓接收端能信任來源。

演算法與編碼選項

Toova 支援 HMAC-SHA256、HMAC-SHA1 與 HMAC-SHA512。SHA-256 是現代預設值。請選擇與您整合的服務文件相符的演算法。輸出預設為十六進位,並提供 Base64 與 Base64-URL 變體——大多數 webhook 提供者會指定特定格式,切換前請查閱對方文件。

純本機簽章

簽章完全在您的瀏覽器中計算。您的訊息與密鑰從不離開頁面。這一點很重要,因為密鑰一旦外流,任何人都能偽造合法簽章——把密鑰貼到第三方表單就等於把系統交出去。Toova 能安全地用來除錯正式環境的 webhook、驗證簽章,以及探索 API 整合。

常見問題

HMAC 與一般雜湊有什麼差別?: 一般雜湊對任何輸入都具有確定性——任何人都能算出。HMAC 則加入了密鑰,只有持有金鑰的雙方才能產生相符的簽章。這也是 HMAC 適合做驗證、而一般雜湊只能做完整性檢查的原因。
我該選哪一種演算法?: 除非整合的服務明確要求別的,否則就用 HMAC-SHA256。SHA-1 在舊系統中仍常見,但不適合用於新設計。SHA-512 在多數情境下其實過頭了,但相對更保守。
金鑰應該是字串還是位元組?: HMAC 接收的是位元組序列。Toova 預設把您的金鑰當作 UTF-8 文字處理,與大多數 API 的作法一致。如果規格寫的是「hex-encoded secret」,請切換金鑰編碼,使位元組與服務期望的相符。
我的密鑰會被送到伺服器嗎?: 不會。簽章完全在您的瀏覽器中執行。密鑰與訊息從不離開裝置,簽章期間 Network 分頁會保持空白。
為什麼我的簽章與服務期望不一致?: 最常見的原因:編碼不一致(十六進位 vs Base64)、payload 末尾有換行,或演算法錯誤。請逐一比對服務文件確認三者都吻合。