HTTPダイジェスト認証(エイチティーティーピーダイジェストニンショウ)とは | 意味や読み方など丁寧でわかりやすい用語解説

HTTPダイジェスト認証は、ウェブサーバーとクライアント間でユーザー認証を行うためのHTTP認証方式の一つである。これは、より古くから存在するHTTP Basic認証が抱えるセキュリティ上の脆弱性、特にパスワードがネットワーク上を平文（暗号化されていない状態）で流れるという問題を解決するために開発された。ダイジェスト認証の核心は、ユーザーのパスワードそのものを直接送信するのではなく、パスワードとサーバーが発行する使い捨てのデータなどを組み合わせた「ハッシュ値」（ダイジェスト）を送信することによって認証を行う点にある。これにより、通信が盗聴されたとしてもパスワード自体が漏洩するリスクを低減できる。

詳細な認証の仕組みを見ていこう。まず、クライアント（ウェブブラウザなど）が、認証によって保護されているウェブサーバー上のリソースにアクセスを試みる。サーバーは、そのリソースへのアクセスには認証が必要であることを認識すると、HTTPステータスコード「401 Unauthorized」をクライアントに返す。この401レスポンスには、「WWW-Authenticate」というヘッダが含まれており、その中に認証方式として「Digest」が指定されるとともに、認証処理に必要な複数のパラメータが付加されている。

このパラメータの中で特に重要なのが「realm」と「nonce」である。realmは、認証の対象となる領域や範囲を示す文字列であり、通常はユーザーに認証ダイアログのタイトルなどで表示される。nonceは「ナンバーワンス」の略で、サーバーが生成する一意の使い捨て文字列である。これは、クライアントが次に認証情報を送る際に必ず含めなければならないもので、リプレイ攻撃（盗聴した認証情報を再利用して不正アクセスを試みる攻撃）を防ぐための鍵となる。

クライアントは401レスポンスを受け取ると、ユーザーに対してユーザー名とパスワードの入力を求める。ユーザーがこれらを入力した後、クライアントは、入力されたユーザー名とパスワード、サーバーから受け取ったrealmとnonce、そしてアクセスしようとしているHTTPメソッド（GETやPOSTなど）、リクエストURIなどの情報を組み合わせて、所定の計算手順に従って「レスポンスダイジェスト」を生成する。この計算には通常、MD5などのハッシュ関数が用いられる。

計算のプロセスは一般的に複数のステップに分かれる。まず、「ユーザー名:realm:パスワード」という文字列から中間ハッシュ値（A1）を生成する。次に、「HTTPメソッド:URI」という文字列から別の中間ハッシュ値（A2）を生成する。そして、最終的なレスポンスダイジェストは、「A1のハッシュ値:nonce:A2のハッシュ値」のような形式の文字列全体をさらにハッシュ化する、という複雑な計算によって導き出される。実際には、クライアントが生成する使い捨ての文字列である「cnonce（client nonce）」や、同じnonceでリクエストを送信した回数を示す「nc（nonce count）」、保護の品質を示す「qop（Quality of Protection）」といった追加のパラメータも計算に含められ、セキュリティを強化する。

クライアントは、生成したレスポンスダイジェストを、ユーザー名、realm、nonce、cnonce、nc、qopなどの情報とともに、「Authorization」ヘッダに含めて、再度サーバーにリクエストを送信する。

サーバーは、このAuthorizationヘッダを受け取ると、クライアントから送られてきた情報（ユーザー名、nonce、cnonce、nc、qop、リクエストURI、HTTPメソッドなど）と、自身のデータベースに保存されているそのユーザーのパスワード情報を用いて、クライアントと全く同じ計算手順でレスポンスダイジェストを独自に生成する。サーバーが計算したダイジェスト値と、クライアントから送られてきたダイジェスト値が完全に一致した場合、サーバーはクライアントの認証が成功したと判断し、要求された保護されたリソースへのアクセスを許可する。

HTTPダイジェスト認証の主要な利点は、前述の通り、パスワード自体がネットワーク上を流れないため、盗聴によるパスワード漏洩のリスクを低減できる点である。また、nonceの導入により、盗聴されたダイジェストが再利用されるリプレイ攻撃に対しても、ある程度の耐性を持つ。

しかし、この認証方式にもいくつかの課題と限界が存在する。一つは、サーバー側でユーザーのパスワードを、ハッシュ化せずに平文で、あるいは可逆的に復元できる形式で保存しておく必要がある点である。これは、サーバーがクライアントからのダイジェストを検証するために、パスワードを用いて同じ計算を再現する必要があるためだ。もしサーバーのパスワードデータベースが侵害された場合、攻撃者はユーザーのパスワードを容易に入手できてしまうリスクがある。

また、HTTPダイジェスト認証は中間者攻撃（Man-in-the-Middle攻撃）に対して完全に安全ではない。攻撃者がクライアントとサーバー間の通信経路に割り込み、認証チャレンジ（WWW-Authenticateヘッダ）やクライアントのレスポンス（Authorizationヘッダ）を傍受・改ざんすることで、認証情報を悪用したり、セッションをハイジャックしたりする可能性が残る。例えば、攻撃者が不正なrealmやnonceをクライアントに送ることで、クライアントをだますことも考えられる。このため、HTTPダイジェスト認証は単独で使用するのではなく、HTTPS（HTTP Secure）と組み合わせて使用することが強く推奨される。HTTPSは通信経路を暗号化し、サーバーの正当性を証明することで、中間者攻撃のリスクを大幅に低減する。

さらに、ダイジェスト認証で一般的に使用されるMD5ハッシュ関数は、現代の計算能力から見て、衝突攻撃（異なる入力から同じハッシュ値が生成される脆弱性）や総当たり攻撃（ブルートフォースアタック）に対して脆弱性が指摘されている。より強力なハッシュ関数（例: SHA-256）を使用する実装も存在するが、広く普及しているのは依然としてMD5である。

これらの理由から、HTTPダイジェスト認証はBasic認証よりもセキュリティレベルが高いものの、現代のウェブアプリケーションで求められる最高レベルのセキュリティ要件を満たすには不十分な場合がある。特に高度なセキュリティが要求されるシステムでは、HTTPSとの併用はもちろん、クライアント証明書認証、OAuth、OpenID Connectといった、より現代的で堅牢な認証プロトコルの利用も検討されるべきである。