【実務・中級編】HTTP Digest認証のチャレンジ・レスポンス方式とnonceの役割 – HTTPプロトコル・通信規格実践ガイド

なぜ今さらDigest認証なのか？――「パスワードをさらさない」という執務の矜持

ネットワークエンジニアとして現場に立っていると、若手から「Basic認証じゃダメなんですか？ SSL/TLSで暗号化してるし、HTTPSなら平気でしょ？」という質問をよく受ける。確かにHTTPSは通信経路を暗号化する。しかし、アーキテクトの視点から言えば、それは「配送業者に鍵付きのトラックを使わせている」に過ぎない。もしサーバー側のログや、プロキシのキャッシュ、あるいはサーバー管理者の端末に平文のパスワードが残ったら？

HTTP Digest認証は、古臭い遺物ではない。「パスワードそのものをネットワーク上に流さない」という、プロトコル設計における一つの美学であり、現代のWeb API設計においても「物理的な制約でHTTPSが担保しきれない環境」や「多層防御の要」として知っておくべき必須の知識だ。

今日は、Digest認証の心臓部である`nonce`（ナンス）と、その通信シーケンスを深掘りしていこう。

—

1. Digest認証の魔法：パスワードは「混ぜるな危険」

Digest認証の最大の功績は、パスワードをハッシュ関数の「素材」として使い、一度もサーバーに送信しない点にある。

認証の裏側では、以下のような計算が行われている。
`HA1 = MD5(username:realm:password)`

この`HA1`を計算した上で、さらにクライアントから送られてきた`nonce`や`uri`と混ぜ合わせてレスポンスを生成する。もし攻撃者がパケットを盗聴しても、手に入るのは「使い捨てのハッシュ値」だけであり、元のパスワードを逆算するのは事実上不可能だ。

—

2. nonceの役割：時を刻む「使い捨ての鍵」

Digest認証における`nonce`（Number used ONCE）は、リプレイ攻撃を封じるための重要な防波堤だ。

もし`nonce`がなかったらどうなるか？攻撃者はキャプチャした正しいレスポンス文字列をそのまま再送するだけで、認証を突破できてしまう。これを防ぐために、サーバーはリクエストごとに（あるいは一定期間ごとに）ユニークな`nonce`を生成し、クライアントに送りつける。

サーバーの役割: クライアントへ「このnonceを使って計算し直せ」というチャレンジを投げる。
クライアントの役割: 受け取った`nonce`を計算に含め、特定の「期限付きのハッシュ」を作成する。

サーバー側でこの`nonce`の生存期間を適切に管理することで、古いリクエストや不正な再送を即座に弾くことができる。ここが運用上のキモだ。

—

3. 実践：Digest認証の通信フローを紐解く

実際にどのようなやり取りが行われているのか、シーケンスを追ってみよう。

ステップ1：チャレンジ

クライアントがリクエストを投げると、サーバーは `401 Unauthorized` を返し、`WWW-Authenticate` ヘッダーで「ルール」を伝える。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm=”SecretArea”, qop=”auth”, nonce=”dcd98b7102dd2f0e8b11d0f600bfb0c093″

ステップ2：レスポンス

クライアントは受け取った `nonce` を使い、ハッシュを生成して再送する。

Authorization: Digest username=”admin”, realm=”SecretArea”, nonce=”dcd98b7102dd2f0e8b11d0f600bfb0c093″, uri=”/api/data”, qop=auth, nc=00000001, cnonce=”0a4f113b”, response=”6629fae489330623a3155556″

nc (nonce count): 同じnonceを何回使ったか。リプレイ攻撃を防ぐためのカウンタ。
cnonce: クライアント側で生成するランダム値。

—

4. コードで検証する：Pythonによるシミュレーション

現場でトラブルが起きたとき、Wiresharkのパケットを眺めるだけでなく、自分で再現コードを書くのが一番の近道だ。`requests`ライブラリを使えば、驚くほど簡単に実装できる。

import requests
from requests.auth import HTTPDigestAuth

認証が必要なエンドポイント
url = “http://example.com/api/secure”

HTTPDigestAuthを使うだけで、裏側でnonceのやり取りやハッシュ計算を自動化してくれる
運用現場では、まずはこのライブラリで疎通確認するのが鉄則
auth = HTTPDigestAuth(‘admin’, ‘password123’)

try:
response = requests.get(url, auth=auth)
response.raise_for_status()
print(“認証成功:”, response.json())
except requests.exceptions.HTTPError as e:
# 401が返ってきた場合、ヘッダーにnonceが含まれているかデバッグする
print(“認証失敗:”, e)

実務上のTips：デバッグと運用

最後に、現場で泣きを見ないためのTipsをいくつか伝授しよう。

1. MD5の呪縛: Digest認証の多くはMD5を利用している。現代のセキュリティ基準ではMD5は脆弱とされるため、可能であれば `algorithm=SHA-256` を指定することを強く推奨する。
2. nonceの期限切れ: サーバー側の負荷が高まると、`nonce`の生成速度と検証速度が追いつかず、認証エラー（401）が頻発することがある。その場合、サーバー側の`nonce`有効期限設定を見直す必要がある。
3. ブラウザのキャッシュ: ChromeやEdgeなどのブラウザは、一度Digest認証に成功するとそのセッション情報をガッツリ保持する。開発中に認証設定を変更した際は、シークレットモードを使うか、ブラウザを完全に再起動してくれ。

Digest認証は、古典的でありながら「なぜそうするのか」というプロトコルの本質が詰まったプロトコルだ。トラブルシュートの際は、パケットの `nonce` がサーバーの期待値と一致しているか、`nc`（カウンタ）が異常に増えていないかを確認すること。

ネットワークは嘘をつかない。挙動が怪しいときは、必ずプロトコルスタックのどこかに「論理的な矛盾」が隠れているものだ。健闘を祈る。