【開發筆記】摘要認證 SHA-256 校驗 response 算法

雖然現在應該很少人自己撰寫生成 SHA-256 編碼的摘要請求，但是在年歲久遠的商務內部系統，很多事情只能自己來（踩過坑的你會懂的 T_T）

HTTP 認證

儘管網路連線方式在 2022 年的今天，相較 20 年前應運了不少新的技術問世。不過在多數情況下，終端用戶目前所採用的連線方式，基本上還是以 HTTP 的請求－反饋為主。

當然說到連線傳輸，不能不提到的就是認證方式。從早期 Basic Authentication 和 Digest Authentication，後來 Twitter 引領風騷的 OAuth，再到目前方興未艾的 JSON Web Tokens (JWT)，都是建構 HTTP 請求與伺服器互動取得訊息過程中，不可或缺的一環。

SHA-256 / MD5 編碼的摘要認證

比較起來雖然起始年代已經久遠，時至今日 Basic 和 Digest 認證還是有其運用上的價值。其中 Digest 認證經歷了後續的安全性加強，在保護能力上提供了更佳明文攻擊與密碼分析的防禦能力。

實作流程上，無論是 SHA-256 或是 MD5 編碼， response 算法包含的變量，都會受到 qop 宣告所影響。

# 當 qop 未指定時，response 計算帶上 nonce 即可
response = H(A1:nonce:A2)

# 當 qop 指定為 auth 或 auth-int，response 計算還需要帶上其他屬性的變量如下：
response = H(A1:nonce:nc:cnonce:qop:A2)

# 留意 H(...) 可以是 MD5 或是 SHA-256 編碼

至於 A1 第一條哈希值的計算都是固定的，也就是：

A1 = H(username:realm:password)

而 A2 第二條哈希值的計算同樣會受到 qop 指定的內容所影響

# 當 qop 指定為 auth 時
A2 = H(method:digest-uri)

# 當 qop 指定為 auth-int 時
A2 = H(method:digest-uri:H(entity-body))

總有需要自己算的時候

可能有人會疑問，這些驗證過程不是有現成的程式庫可以引用嗎？在一些主要的執行平台上或許如此。但總有這樣的時候，特別是在年歲已經比較久遠的內部系統，對於 realm，nonce，nc 有額外客製化的定義時，就算有程式庫可以引用也是沒戲。所以稍微了解複習一下這些富有歷史的基本校驗方式也是不錯的，沒準哪天就會遇到了。