はじめに
本資料は、Webサーバーで使われる「HTTPダイジェスト認証」について、基礎から実務で役立つ点まで分かりやすく整理した入門ガイドです。
この資料の目的
ダイジェスト認証の仕組み、Basic認証との違い、実際の通信フロー、そしてセキュリティ上の特徴とメリットを順を追って説明します。設計や運用の判断材料を提供し、社内ツールや簡易なアクセス制限に役立てていただくことを目的とします。
想定する読者
Webアプリの開発者、運用担当者、または社内システムの認証方法を検討している方を想定します。専門知識が浅くても理解できるように、専門用語は最小限にとどめ、具体例を交えて解説します。
本資料の進め方
第2章以降で順に仕組みと利点、通信の手順を解説します。章ごとに図や具体例を使い、実践で参考になるように構成しています。まずは基礎を押さえ、その後で応用や比較点をご覧ください。
ダイジェスト認証とは何か
概要
ダイジェスト認証は、HTTPで使われる認証方式の一つで、IDとパスワードをそのまま送らず、ハッシュ（ダイジェスト）を使って照合する仕組みです。ブラウザ標準の認証ダイアログで使える簡易な方式で、Basic認証と同じ使いやすさを保ちながら平文送信を避けます。
仕組み（ざっくり）
サーバーが「認証が必要」と応答すると、ブラウザはサーバー提示の情報（realmやnonceなど）を受け取ります。ブラウザはID・パスワードと提示情報を組み合わせてハッシュを計算し、そのハッシュだけを送ります。サーバーは同じ計算を行い、値が一致すれば認証を通します。
何が送られるか
送られるのはユーザー名や計算済みのハッシュ、サーバーのnonceなどで、パスワードそのものは送信しません。これにより盗聴でパスワードが直接漏れるリスクを下げます。
Basic認証との違い
見た目は似ていますが、Basic認証はパスワードを平文（Base64でエンコード）で送ります。ダイジェスト認証はハッシュにより直接の漏洩を防ぎ、より安全性が高いとされます。
注意点（簡単に）
ダイジェスト認証は安全性を高めますが、使われるハッシュ関数やnonceの扱いによっては弱点があります。詳しい仕組みや通信の流れは次章で解説します。
ダイジェスト認証が解決しようとした問題
背景
ネットワーク越しの認証では、利用者のIDとパスワードを安全にやり取りすることが重要です。盗聴や使い回しによって認証情報が漏れると、第三者が不正にアクセスできます。
Basic認証の問題点
Basic認証はIDとパスワードをまとめてBase64で送るだけです。Base64は暗号化ではないため、通信が傍受されると容易に元の文字列に戻せます。つまりパスワードがそのまま漏れてしまい、使い回しやリプレイ（過去のやり取りを再送して認証する攻撃）に弱い点が問題です。
ダイジェスト認証で解決すること
ダイジェスト認証はパスワードそのものを送らず、パスワードから計算したハッシュ値を使います。さらにサーバーが毎回異なる乱数（nonce）を出すことで、同じハッシュを繰り返し使えないようにします。これにより通信を傍受されても元のパスワードを復元されにくく、リプレイ攻撃も防げます。
身近な例でイメージすると
鍵の実物を渡す代わりに、鍵の持ち主だけが作れる“印”を毎回交換するイメージです。印だけでは元の鍵を再現できず、過去の印を再利用しても効力がない、という仕組みです。
ダイジェスト認証の仕組みと通信フロー
概要
ダイジェスト認証はチャレンジ・レスポンス方式で、平文のパスワードを繰り返し送らずに認証を行います。サーバーがチャレンジ（nonceなど）を送り、クライアントがその情報を使ってハッシュ値を返す仕組みです。
通信の基本フロー
- クライアントが保護資源へアクセスします。
- サーバーは「401 Unauthorized」とともに、WWW-Authenticate: Digest ヘッダー（realm、nonce、algorithm、qopなど）を返します。
- ブラウザはユーザー名とパスワードを求めます。入力後、クライアントはrealm、nonce、HTTPメソッド、URI、（qopがあれば）cnonceやnonce countを使ってハッシュ値を計算します。
- クライアントはAuthorization: Digest ヘッダーに計算結果を載せて再リクエストします。
- サーバーは同じ手順でハッシュを再計算し、送信された値と比較して合致すれば認証を許可します。
ハッシュ計算（簡単な式と例）
- HA1 = MD5(username:realm:password)
- HA2 = MD5(method:uri)
- response = MD5(HA1:nonce:nonceCount:cnonce:qop:HA2) （qop指定がある場合）
例：username=alice, realm=example, password=secret, method=GET, uri=/page のとき、それぞれをMD5で計算して最終的なresponseを作ります。
サーバー側の検証
サーバーはユーザー情報（通常はパスワードのハッシュ）を基に同じHA1を作り、同様の手順でresponseを計算します。一致すれば認証成功です。
セキュリティ上の特徴とメリット
パスワードそのものを送らない
ダイジェスト認証はパスワードを直接送信しません。代わりに、パスワードなどから計算したハッシュ値を送ります。たとえば、パスワード”password”の代わりに、そのハッシュ（数字の列）を送るイメージです。盗聴者がそのハッシュを見ても、元のパスワードをすぐに復元できない点が大きな利点です。
リプレイ攻撃への対策
サーバー側が発行するnonce（ナンス）や、クライアントが生成するcnonceを使います。これらは一度きりや短時間で有効な値です。同じハッシュを再送してもサーバーが拒否するため、過去の通信を再利用するリプレイ攻撃を防げます。
盗聴・中間者攻撃に対する評価
ダイジェストはBasic認証より安全性が高いです。とはいえ、完全無欠ではありません。ハッシュ計算の方法やサーバー側の保存方法（ハッシュそのものを安全に保管するか）によってリスクが残ります。オフラインで総当たり攻撃を受ける可能性や、古いアルゴリズム（例：MD5）の脆弱性に注意が必要です。
運用上のメリットと注意点
メリットは導入の容易さと既存のHTTP仕組みとの親和性です。パスワードを直接送らない点で安全性が向上します。ただし、サーバー側でのハッシュ保護、強いハッシュ関数の採用、可能ならTLS（HTTPS）の併用を推奨します。これにより総合的な安全性をさらに高められます。
