Loading article…
ダイジェストアクセス認証は、 Webサーバーがユーザー名やパスワードなどの認証情報をユーザーのWebブラウザとネゴシエートするために使用できる合意された方法の1つです。これは、オンラインバンキングの取引履歴などの機密情報を送信する前に、ユーザーの身元を確認するために使用できます。ダイジェストアクセス認証は、ユーザー名とパスワードをネットワーク経由で送信する前にハッシュ関数を適用します。対照的に、基本アクセス認証はハッシュ化の代わりに簡単に可逆なBase64エンコードを使用するため、 TLSと組み合わせて使用しない限り安全ではありません。[ 1 ]
技術的には、ダイジェスト認証は、リプレイ攻撃を防ぐためにnonce値を使用した暗号学的ハッシュの応用例です。HTTPプロトコルを使用します。
RFC 2831で規定されているSASLメカニズムとしてのDIGEST-MD5は、2011年7月以降廃止されています。[ 2 ]
ダイジェストアクセス認証は、元々RFC 2069（HTTPの拡張：ダイジェストアクセス認証）で規定されました。RFC 2069は、サーバーが生成するnonce値によってセキュリティが維持される、おおむね従来型のダイジェスト認証方式を規定しています。認証応答は次のように構成されます（HA1とHA2は文字列変数の名前、methodはHTTPメソッド動詞、digestURIはアクセスするURIです）。
HA1 = MD5(ユーザー名:レルム:パスワード) HA2 = MD5(メソッド:ダイジェストURI) レスポンス = MD5(HA1:nonce:HA2) MD5ハッシュは16バイトの値です。応答の計算に使用されるHA1とHA2の値は、それぞれMD5ハッシュの16進数表現（小文字）です。
RFC 2069 は後にRFC 2617 ( HTTP 認証: 基本アクセス認証とダイジェストアクセス認証)に置き換えられました。RFC 2617 では、ダイジェスト認証にいくつかのオプションのセキュリティ強化が導入されました。 「保護品質」(qop)、クライアントによってインクリメントされる nonce カウンタ、およびクライアントによって生成されるランダム nonce です。これらの強化は、例えば選択平文攻撃や暗号解読から保護するように設計されています。
アルゴリズムディレクティブの値が「MD5」または未指定の場合、HA1は
HA1 = MD5(ユーザー名:レルム:パスワード) アルゴリズムディレクティブの値が「MD5-sess」の場合、HA1は
HA1 = MD5(MD5(username:realm:password):nonce:cnonce) qop ディレクティブの値が「auth」または未指定の場合、HA2 は
HA2 = MD5(メソッド:ダイジェストURI) qop ディレクティブの値が「auth-int」の場合、HA2 は
HA2 = MD5(メソッド:ダイジェストURI:MD5(entityBody)) qop ディレクティブの値が「auth」または「auth-int」の場合は、以下のようにレスポンスを計算します。
レスポンス = MD5(HA1:nonce:nonceCount:cnonce:qop:HA2) qopディレクティブが指定されていない場合は、以下のように応答を計算します。
レスポンス = MD5(HA1:nonce:HA2) 上記からわかるように、qopが指定されていない場合は、よりシンプルなRFC 2069規格が適用されます。
2015年9月、RFC 7616はRFC 2617に代わり、4つの新しいアルゴリズム「SHA-256」、「SHA-256-sess」、「SHA-512-256」、「SHA-512-256-sess」を追加しました。このエンコーディングは「MD5」および「MD5-sess」アルゴリズムに相当し、MD5ハッシュ関数がSHA-256およびSHA-512-256に置き換えられています。
2021年10月 Firefox 93 [ 3 ]は、ダイジェスト認証に「SHA-256」および「SHA-256-sess」アルゴリズムを実装しました。しかし、「SHA-512-256」、「SHA-512-256-sess」アルゴリズムおよびユーザー名ハッシュのサポートはまだありません。[ 4 ]
2023年8月 Chromium 117 では「SHA-256」と「SHA-256-sess」が実装されました。[ 5 ] [ 6 ]
HTTPダイジェスト認証で使用されるMD5計算は「一方向」であるように意図されており、出力のみがわかっている場合は元の入力を特定することは困難であるはずです。しかし、パスワード自体が単純すぎる場合は、考えられるすべての入力をテストして一致する出力を見つけることが可能です（総当たり攻撃）。これは、辞書や適切なルックアップリスト によって助けられる可能性があり、MD5の場合はこれらは容易に入手できます。[ 7 ]
HTTP スキームは、 1993 年にCERNのPhillip Hallam-Bakerによって設計されましたが、鍵付きハッシュメッセージ認証コード ( HMAC ) の開発など、認証システムのその後の改良は取り入れていません。使用されている暗号化構造は MD5 ハッシュ関数に基づいていますが、2004 年時点では、衝突攻撃は平文 (つまりパスワード) が不明なアプリケーションには影響しないと考えられていました。[ 8 ]しかし、2006 年の主張[ 9 ]により、他の MD5 アプリケーションにもいくらかの疑問が生じています。
HTTPダイジェスト認証は、従来のダイジェスト認証方式よりも安全性が高くなるように設計されており、例えば「（例）CRAM-MD5よりもはるかに強力である」(RFC 2617)。
HTTPダイジェスト認証のセキュリティ上の強みには、以下のようなものがあります。
ダイジェスト認証にはいくつかの欠点がある。
また、MD5アルゴリズムはFIPSで許可されていないため、HTTPダイジェスト認証はFIPS認定[注1 ]暗号モジュールでは機能しません。
最も一般的な方法は、HTTP+HTMLフォームベースの認証（平文）プロトコル、あるいは稀に基本アクセス認証を使用することです。これらの脆弱な平文プロトコルをHTTPSネットワーク暗号化と併用することで、ダイジェストアクセス認証が防止しようとする多くの脅威を解決できます。しかし、HTTPSを使用するには、エンドユーザーが毎回正しいURLにアクセスしていることを正確に検証し、信頼できないサーバーにパスワードを送信してフィッシング攻撃を防ぐ必要があります。ユーザーはしばしばこれを怠るため、フィッシングが最も一般的なセキュリティ侵害の形態となっています。
ウェブベースのアプリケーションで時折使用される強力な認証プロトコルには、以下のようなものがあります。
以下の例は元々RFC 2617で示されていたもので、ここでは各リクエストとレスポンスで想定される全文を示すために拡張されています。なお、 2005年4月現在、 保護コードの品質は「auth」（認証）のみを対象としています。 OperaとKonquerorのWebブラウザのみが「auth-int」（整合性保護付き認証）をサポートしていることが知られています。[ 12 ] [ 13 ]仕様ではHTTPバージョン1.1について言及されていますが、ここに示されているように、このスキームはバージョン1.0のサーバーにも正常に追加できます。[ 14 ]
この典型的な取引は、以下の手順で構成されます。
GET /dir/index.html HTTP / 1.0 Host : localhost（その後に改行が続く。改行はキャリッジリターンとラインフィードの形式である。）[ 15 ]
HTTP / 1.0 401 Unauthorized Server : HTTPd/0.9 Date : Sun, 10 Apr 2014 20:26:47 GMT WWW-Authenticate : Digest realm="testrealm@host.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Type : text/html Content-Length : 153< ! DOCTYPE html > <html> <head> < meta charset = " UTF - 8 " / > <title>エラー</title> </head> <body> <h1> 401 Unauthorized . </h1> </body> </html>GET /dir/index.html HTTP / 1.0 Host : localhost Authorization : Digest username="Mufasa", realm="testrealm@host.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/index.html", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"（以前と同様に、空白行が続く。）
HTTP / 1.0 200 OKサーバー: HTTPd/0.9日付: 2005年4月10日(日) 20:27:03 GMTコンテンツタイプ: text/htmlコンテンツ長: 7984（その後に空白行と制限付きページのHTMLテキストが続く）
「応答」値は、以下の3つのステップで計算されます。複数の値を組み合わせる場合は、コロンで区切ります。
"GET"）"/dir/index.html"。結果はHA2と呼ばれます。サーバーはクライアントと同じ情報を持っているため、同じ計算を実行することで応答を確認できます。上記の例では、結果は次のように生成されます。ここで、はMD5ハッシュMD5()を計算するために使用される関数を表し、バックスラッシュは継続を表し、表示されている引用符は計算には使用されません。
RFC 2617に示されている例を実行すると、各ステップで以下の結果が得られます。
HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" ) = 939e7578ed9e3c518a452acee763bce9 HA2 = MD5( "GET:/dir/index.html" ) = 39aff3a2bab6126f332b942af96d3366 レスポンス = MD5( "939e7578ed9e3c518a452acee763bce9:\ dcd98b7102dd2f0e8b11d0f600bfb0c093:\ 00000001:0a4f113b:auth:\ 39aff3a2bab6126f332b942af96d3366" ) = 6629fae49393a05397450978507c4ef1
この時点で、クライアントは別のリクエストを行うことができ、サーバーの nonce 値を再利用しますが (サーバーは「401」レスポンスごとに新しい nonce を発行します)、新しいクライアント nonce (cnonce) を提供します。後続のリクエストでは、16 進数のリクエスト カウンター (nc) は、最後に使用した値よりも大きくなければなりません 。そうでないと、攻撃者は同じ認証情報を使用して古いリクエストを「リプレイ」できてしまいます。サーバーは、発行した nonce 値ごとにカウンターが増加し、不正なリクエストを適切に拒否することを保証する必要があります。当然ながら、メソッド、URI、および/またはカウンター値を変更すると、異なるレスポンス値が返されます。
サーバーは、最近生成したnonce値を記憶しておく必要があります。また、各nonce値が発行された日時を記憶し、一定期間経過後に有効期限切れとすることもできます。有効期限切れのnonce値が使用された場合、サーバーはステータスコード「401」を返し、stale=TRUE認証ヘッダーに情報を追加して、クライアントが新しいnonce値を使用して再送信するように指示する必要があります。その際、ユーザーに別のユーザー名とパスワードの入力を求める必要はありません。
サーバーは期限切れのnonce値を保持する必要はありません 。認識されない値はすべて期限切れであると単純に想定すればよいのです。また、サーバーは各nonce値を一度だけ返すように設定することもできますが、その場合、クライアントはすべてのリクエストを繰り返す必要があります。サーバーのnonceを即座に期限切れにしても、クライアントがそれを使用する機会がなくなるため、機能しないことに注意してください。
.htdigest は、Apache HTTP Serverのダイジェスト認証で使用するユーザー名、レルム、パスワードを保存するフラットファイルです。ファイル名は.htaccess設定ファイルで指定され、任意の名前を使用できますが、「.htdigest」が正式な名前です。ファイル名はドットで始まります。これは、ほとんどのUnix 系オペレーティングシステムでは、ドットで始まるファイルは隠しファイルとみなされるためです。このファイルは、ユーザーの追加や更新、パスワードの適切なエンコードを行うシェルコマンド「htdigest」で管理されることがよくあります。
「htdigest」コマンドは、dpkgパッケージ管理システムではapache2-utilsパッケージに、 RPMパッケージ管理システムではhttpd-toolsパッケージに含まれています。
htdigest コマンドの構文: [ 16 ]
htdigest [ -c ]パスワードファイル レルム ユーザー名
.htdigest ファイルの形式: [ 16 ]
user1:レルム:5ea41921c65387d904834f8403185412 ユーザー2:レルム:734418f1e487083dc153890208b79379
セッション開始プロトコル（SIP）は、基本的に同じダイジェスト認証アルゴリズムを使用します。これはRFC 3261で規定されています。
ほとんどのブラウザは仕様をほぼ完全に実装していますが、認証情報チェックやMD5セッションアルゴリズムなどの特定の機能を除いているものもあります。サーバーがこれらのオプション機能の処理を要求する場合、クライアントは認証できない可能性があります（ただし、Apacheのmod_auth_digestもRFC 2617を完全に実装しているわけではないことに注意してください）。
HTTPS 上の基本認証と比較した Digest 認証の欠点のため、多くのソフトウェアで非推奨となっています。例:
{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）{{cite web}}: CS1 maint: 複数の名前: 著者リスト (リンク)