HMAC 驗證

概念 2026/8/28

定義

Hash-based Message Authentication Code，使用密鑰與雜湊函數對訊息進行認證的機制。文章中的 SHA-256 簽章是 HMAC 概念的簡化實作——將密鑰與訊息串接後直接計算 Hash，而非使用標準 HMAC 算法（HMAC-SHA256）。

文章使用的是「密鑰 + 欄位直接串接後 SHA-256」的方式，而非嚴格的 HMAC-SHA256。（api-security-design-connection-key）
標準 HMAC 會對密鑰做 padding 和兩次 Hash，安全性略高於直接串接。
台灣金流業者的做法也多為直接串接（非標準 HMAC），但在實務上已足夠。
後續做法升級：LINE 登入中繼站改用標準 HMAC-SHA256 簽 OAuth state 與 Webhook 轉發，不再用直接串接。（line-login-relay-cloudflare-workers）
簽章對象要固定：state 簽在 base64url 編碼後的字串而非原始 JSON，避免欄位順序不同造成驗簽失敗。（line-login-relay-cloudflare-workers）
驗簽必須用未經解析的原始 bytes：先 JSON.parse 再 stringify 回來，欄位順序或空白差一點 HMAC 就對不上。（line-login-relay-cloudflare-workers）
比對要走常數時間演算法（timingSafeEqual），一般字串比對會因「第幾個字元開始不同」洩漏時間差，可被用來逐字元猜金鑰。（line-login-relay-cloudflare-workers）
反面案例（雙用性）：一個 WordPress 後門（easypost）對每個請求要求 Token ID、時間戳（±300 秒）、SHA256 雜湊、HMAC 簽章，並用公鑰簽章驗證做 OTA 自我更新——把防禦端的縱深驗證原封不動搬來保護自己的 C2 入口，不讓資安研究員或其他駭客劫走。簽章驗證是中性工具，攻守皆可用。（wordpress-hacked-forensic-analysis，見 [[持久化攻擊]]）

~~文章中的實作嚴格來說不是 HMAC，而是簡化版的密鑰雜湊。在低風險場景下差異可忽略，但高安全需求場景應使用標準 HMAC-SHA256。~~
已解（2026-08-28）：line-login-relay-cloudflare-workers 在一組主憑證服務所有租戶的高風險場景改用標準 HMAC-SHA256，正是本條目原先建議的方向。兩篇並非觀點衝突，而是同一團隊按風險等級選用不同強度：點對點低風險場景用簡化版可接受，多租戶場景用標準版。