ダイジェストアクセス認証
Method of negotiating credentials between web server and browser
HTTP
Request methods
Header fields
Response status codes
Security access control methods
Security vulnerabilities

ダイジェストアクセス認証は、 WebサーバーがユーザーのWebブラウザとユーザー名やパスワードなどの認証情報をネゴシエートするために使用できる合意された認証方式の一つです。これは、オンラインバンキングの取引履歴などの機密情報を送信する前に、ユーザーの本人確認に使用できます。ユーザー名とパスワードをネットワークに送信する前に、ハッシュ関数を適用します。一方、ベーシックアクセス認証はハッシュではなく、簡単に元に戻せるBase64エンコードを使用するため、 TLSと併用しない限り安全ではありません。

技術的には、ダイジェスト認証は、リプレイ攻撃を防ぐためにノンス値を使用した暗号ハッシュの応用です。HTTPプロトコルを使用します。

RFC  2831で規定されたSASLメカニズムとしてのDIGEST-MD5は、2011年7月以降廃止されています。[1]

概要

ダイジェストアクセス認証は、 RFC  2069（HTTP拡張：ダイジェストアクセス認証）で最初に規定されました。RFC 2069は、サーバー生成のノンス値によってセキュリティが維持される、従来のダイジェスト認証スキームを概ね規定しています。認証レスポンスは以下のように構成されます（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）、クライアントによってインクリメントされるノンスカウンタ、クライアントによって生成されるランダムノンスなどです。これらの強化機能は、例えば選択平文攻撃による暗号解読から保護するように設計されています。

アルゴリズムディレクティブの値が「MD5」または未指定の場合、HA1は 

HA1 = MD5(ユーザー名:レルム:パスワード)

アルゴリズムディレクティブの値が「MD5-sess」の場合、HA1は 

HA1 = MD5(MD5(ユーザー名:レルム:パスワード):nonce:cnonce)

qopディレクティブの値が「auth」または指定されていない場合、HA2は 

HA2 = MD5(メソッド:ダイジェストURI)

qopディレクティブの値が「auth-int」の場合、HA2は 

HA2 = MD5(メソッド:ダイジェストURI:MD5(エンティティ本体))

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月[update]、Firefox 93 [2]はダイジェスト認証に「SHA-256」および「SHA-256-sess」アルゴリズムを実装しました。ただし、「SHA-512-256」、「SHA-512-256-sess」アルゴリズム、およびユーザー名ハッシュのサポートはまだ不足しています。[3] [要検証]

2023年8月[update]、Chromium 117は「SHA-256」を実装しました。[4]

MD5セキュリティがダイジェスト認証に与える影響

HTTPダイジェスト認証で使用されるMD5計算は「一方向」であることが意図されており、出力のみが判明している場合、元の入力を特定することは困難であることを意味します。しかし、パスワード自体が単純すぎる場合、すべての可能な入力をテストし、一致する出力を見つけることが可能になる可能性があります（ブルートフォース攻撃）。MD5の場合、辞書や適切な検索リストが容易に利用できる場合もあります。[5]

HTTP方式は1993年にCERNのフィリップ・ハラム＝ベーカーによって設計されましたが、鍵付きハッシュメッセージ認証コード（ HMAC）の開発など、その後の認証システムの改良は組み込まれていません。使用されている暗号構造はMD5ハッシュ関数に基づいていますが、 2004年当時は、平文（パスワードなど）が不明なアプリケーションでは衝突攻撃の影響を受けないと一般的に考えられていました。 [6]しかし、2006年の主張[7]は、他のMD5アプリケーションにも疑問を投げかけています。

HTTPダイジェスト認証の考慮事項

利点

HTTP ダイジェスト認証は、従来のダイジェスト認証方式よりも安全になるように設計されています。たとえば、「(例) CRAM-MD5よりも大幅に強力です...」(RFC 2617)。

HTTP ダイジェスト認証のセキュリティ上の強みは次のとおりです。

デメリット

ダイジェスト アクセス認証にはいくつかの欠点があります。

  • ウェブサイトは、エンドユーザーに表示されるユーザーインターフェイスを制御することはできません。
  • RFC 2617のセキュリティオプションの多くはオプションです。サーバー側で保護品質（QOP）が指定されていない場合、クライアントはセキュリティレベルが低いレガシーRFC 2069モードで動作します。
  • ダイジェストアクセス認証は、中間者（MITM）攻撃に対して脆弱です。例えば、MITM攻撃者はクライアントに基本アクセス認証または従来のRFC2069ダイジェストアクセス認証モードを使用するように指示することができます。さらに、ダイジェストアクセス認証では、クライアントがサーバーのIDを検証するメカニズムが提供されていません。
  • サーバーは、パスワード自体の代わりに、HA1 = MD5(ユーザー名:レルム:パスワード) を保存できます。しかし、保存されたHA1が漏洩した場合、攻撃者はパスワード自体にアクセスした場合と同様に、有効なレスポンスを生成し、レルム内の文書にアクセスできるようになります。したがって、HA1値のテーブルは、平文のパスワードを含むファイルと同様に安全に保護する必要があります。[9]
  • ダイジェストアクセス認証は、パスワードを保存するときに強力なパスワードハッシュ（ bcryptなど）の使用を防止します（パスワード、またはダイジェストされたユーザー名、レルム、パスワードのいずれかが回復可能である必要があるため）。

また、MD5アルゴリズムはFIPSでは許可されていないため、HTTPダイジェスト認証はFIPS認定[注1]暗号モジュールでは機能しません。

代替認証プロトコル

最も一般的なアプローチは、HTTP+HTMLフォームベースの認証クリアテキストプロトコル、あるいは稀にベーシックアクセス認証を使用することです。これらの脆弱なクリアテキストプロトコルをHTTPSネットワーク暗号化と併用することで、ダイジェストアクセス認証が防御しようとしている多くの脅威を解決できます。しかし、このHTTPSの使用では、エンドユーザーが毎回正しいURLにアクセスしていることを正確に検証する必要があります。そうしないと、信頼できないサーバーにパスワードが送信され、フィッシング攻撃につながる可能性があります。ユーザーはしばしばこの検証を怠るため、フィッシングが最も一般的なセキュリティ侵害の形態となっています。

時々使用される Web ベースのアプリケーション用の強力な認証プロトコルには、次のようなものがあります。

説明付きの例

以下の例は元々RFC 2617で示されていたものですが、ここでは各リクエストとレスポンスに期待される全文を示すために拡張されています。「auth」（認証）品質保護コードのみがカバーされていることに注意してください。2005年4月現在[update]、「auth-int」（整合性保護付き認証）をサポートしているのはOperaとKonquerorのWebブラウザのみです。 [要出典] [要更新]仕様ではHTTPバージョン1.1が言及されていますが、ここに示すように、このスキームはバージョン1.0のサーバーにも正常に追加できます。

この典型的なトランザクションは次の手順で構成されます。

  1. クライアントは認証が必要なページを要求しますが、ユーザー名とパスワードを提供しません。[注 2]通常、これはユーザーが単にアドレスを入力したか、ページへのリンクをたどったことが原因です。
  2. サーバーは401「Unauthorized」応答コードで応答し、認証領域と、 nonceと呼ばれるランダムに生成された使い捨ての値を提供します。
  3. この時点で、ブラウザは認証領域（通常はアクセス先のコンピュータまたはシステムの説明）をユーザーに提示し、ユーザー名とパスワードの入力を求めます。ユーザーはこの時点でキャンセルすることもできます。
  4. ユーザー名とパスワードが入力されると、クライアントは同じリクエストを再送信しますが、応答コードを含む認証ヘッダーを追加します。
  5. この例では、サーバーは認証を受け入れ、ページを返します。ユーザー名が無効、またはパスワードが間違っている場合、サーバーは「401」レスポンスコードを返す可能性があり、クライアントはユーザーに再度入力を求めます。
クライアント要求（認証なし）
GET  /dir/index.html  HTTP / 1.0
ホスト:  localhost

（その後にキャリッジリターンとラインフィードの形式で新しい行が続く）。[10]

サーバー応答
HTTP / 1.0  401 不正
サーバー:  HTTPd/0.9
日付: 日曜日、2014年4月10日 20:26:47 GMT 
WWW認証: ダイジェスト realm="testrealm@host.com", 
                        qop="auth,auth-int", 
                        nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 
                        opaque="5ccc069c403ebaf9f0171e9517f40e41"
コンテンツタイプ:  text/html
コンテンツ長:  153

<!DOCTYPE html> 
< html > 
  < head > 
    < meta  charset = "UTF-8"  /> 
    < title >エラー</ title > 
  </ head > 
  < body > 
    < h1 > 401 権限がありません。</ h1 > 
  </ body > 
</ html >
クライアントリクエスト（ユーザー名「Mufasa」、パスワード「Circle Of Life」）
GET  /dir/index.html  HTTP / 1.0
ホスト:  localhost
認証:  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
日付:  Sun, 10 Apr 2005 20:27:03 GMT
コンテンツタイプ:  text/html
コンテンツ長:  7984

(その後に空白行と制限されたページの HTML テキストが続きます)。

「レスポンス」値は、以下の3つのステップで計算されます。値が結合されている場合は、コロンで 区切られます。

  1. ユーザー名、認証レルム、パスワードを組み合わせたMD5ハッシュが計算されます。結果はHA1と呼ばれます。
  2. メソッドとダイジェストURIを組み合わせたMD5ハッシュが計算されます（例： と"GET"）"/dir/index.html"。結果はHA2と呼ばれます。
  3. HA1の結果、サーバーノンス（nonce）、リクエストカウンタ（nc）、クライアントノンス（cnonce）、保護品質コード（qop）、およびHA2の結果を組み合わせたMD5ハッシュが計算されます。この結果が、クライアントから提供される「レスポンス」値となります。

サーバーはクライアントと同じ情報を持っているため、同じ計算を実行することでレスポンスを確認できます。上記の例では、結果は以下のようになります。 は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:認証:\
                    39aff3a2bab6126f332b942af96d3366" )
            = 6629fae49393a05397450978507c4ef1

この時点で、クライアントはサーバーの nonce 値を再利用し（サーバーは「401」レスポンスごとに新しい nonce を発行します）、新しいクライアント nonce (cnonce) を提供することで、別のリクエストを行うことができます。後続のリクエストでは、16進数のリクエストカウンタ (nc) が最後に使用した値よりも大きくなければなりません。そうでないと、攻撃者は同じ認証情報を使用して古いリクエストを「リプレイ」してしまう可能性があります。サーバーは、発行した nonce 値ごとにカウンタを増加させ、不正なリクエストを適切に拒否する必要があります。当然のことながら、メソッド、URI、カウンタ値を変更すると、レスポンス値が異なります。

サーバーは、最近生成した nonce 値を記憶しておく必要があります。また、各 nonce 値が発行された日時を記憶し、一定期間後に有効期限を切るように設定することもできます。有効期限切れの値を使用した場合、サーバーは「401」ステータスコードを返してstale=TRUE認証ヘッダーに次の情報を追加し、クライアントが新しい nonce を使用して再送信するよう指示する必要があります。この場合、ユーザーに別のユーザー名とパスワードの入力を求める必要はありません。

サーバーは期限切れのノンス値を保持する必要はありません。認識できないノンス値は期限切れであると単純に判断できます。サーバーが各ノンス値を1回だけ返すようにすることも可能ですが、その場合、クライアントはリクエストごとに同じ処理を繰り返す必要があります。サーバーのノンスをすぐに期限切れにすることは、クライアントがそれを使用する機会を永遠に失うため、機能しないことに注意してください。

.htdigestファイル

.htdigest は、Apache HTTP Serverのダイジェスト認証で使用するユーザー名、レルム、パスワードを保存するためのフラットファイルです。ファイル名は.htaccess設定で指定します。任意の名前を指定できますが、「.htdigest」が標準名です。ファイル名はドットで始まります。これは、ほとんどのUnix 系オペレーティングシステムがドットで始まるファイルを隠しファイルと見なすためです。このファイルは、多くの場合、シェルコマンド「htdigest」で管理されます。このコマンドはユーザーの追加や更新を行うことができ、パスワードを適切にエンコードして使用できます。

「htdigest」コマンドは、dpkgパッケージ管理システムのapache2-utilsパッケージと、 RPM パッケージ管理システムのhttpd-toolsパッケージにあります。

htdigestコマンドの構文：[11] 

htdigest [ -c ]パスワードファイル レルム ユーザー名

.htdigestファイルのフォーマット: [11] 

ユーザー1:レルム:5ea41921c65387d904834f8403185412
ユーザー2:レルム:734418f1e487083dc153890208b79379

SIPダイジェスト認証

セッション開始プロトコル（SIP）は基本的に同じダイジェスト認証アルゴリズムを使用します。これはRFC 3261で規定されています。

ブラウザ実装

ほとんどのブラウザは仕様をほぼ実装していますが、auth-intチェックやMD5-sessアルゴリズムといった特定の機能を除けば、一部のブラウザでは実装されていません。サーバー側でこれらのオプション機能の処理が必要な場合、クライアントは認証できない可能性があります（ただし、Apacheのmod_auth_digestもRFC 2617を完全には実装していないことに注意してください）。

廃止予定

HTTPS 経由の基本認証と比較した場合のダイジェスト認証の欠点のため、多くのソフトウェアでは非推奨となっています。例:

  • ビットバケット[17]
  • Symfony PHPフレームワーク[18]

参照

注記

  1. ^ 以下はFIPS承認アルゴリズムのリストです：「付録A：FIPS PUB 140-2の承認済みセキュリティ機能、暗号モジュールのセキュリティ要件」（PDF）。米国国立標準技術研究所。2014年1月31日。
  2. ^ クライアントは、たとえば以前に Web ブラウザによって保存されている場合、ユーザーにプロンプ​​トを表示せずに、必要なユーザー名とパスワードをすでに持っている場合があります。

参考文献

  1. ^ DIGEST-MD5 を Historic に移行、2011 年 7 月。
  2. ^ 「バグ472823: SHA 256ダイジェスト認証」。Mozilla Bugzilla。
  3. ^ 「Mozilla-central: SHA-256 HTTPダイジェスト認証をサポート」。Mozilla -central。
  4. ^ 「Chrome の機能: RFC 7616 ダイジェスト認証: SHA-256 とユーザー名のハッシュ化をサポート」。
  5. ^ レインボーテーブルのリスト、Project Rainbowcrack。複数のMD5レインボーテーブルが含まれています。
  6. ^ 「ハッシュ衝突に関するQ&A」. Cryptography Research . 2005年2月16日. 2010年3月6日時点のオリジナルよりアーカイブ。[より良い情報源が必要]
  7. ^ Jongsung Kim、Alex Biryukov、Bart Preneel、Seokhie Hong. 「HAVAL、MD4 、MD5、SHA-0、SHA-1に基づくHMACとNMACのセキュリティについて」(PDF) IACR .
  8. ^ Scott Stark (2005年10月8日). 「DIGEST認証 (4.0.4+)」. JBoss . 2015年10月18日時点のオリジナルよりアーカイブ。2013年3月4日閲覧。
  9. ^ Franks, J.; Hallam-Baker, P.; Hostetler, J.; Lawrence, S.; Leach, P.; Luotonen, A.; Stewart, L. (1999年6月). 「HTTP認証：基本認証とダイジェストアクセス認証：パスワードの保存」 . IETF . doi :10.17487/RFC2617. S2CID  27137261. {{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）が必要です
  10. ^ Tim Berners-Lee、Roy Fielding、Henrik Frystyk Nielsen (1996-02-19). 「ハイパーテキスト転送プロトコル - HTTP/1.0: リクエスト」. W3C .{{cite web}}: CS1 maint: multiple names: authors list (link)
  11. ^ ab "htdigest - ダイジェスト認証用のユーザーファイルを管理する". apache.org .
  12. ^ Emanuel Corthay (2002-09-16). 「バグ 168942 - 整合性保護付きダイジェスト認証」Mozilla .
  13. ^ Deomid "rojer" Ryabkov (2023-07-27). 「RFC 7616 HTTPダイジェスト認証：SHA-256とユーザー名ハッシュのサポートを追加」Chromium（ウェブブラウザ） .
  14. ^ Timothy D. Morgan (2010年1月5日). 「HTTPダイジェストの整合性：最近の攻撃を踏まえた新たな視点」(PDF) . vsecurity.com. 2014年7月14日時点のオリジナル(PDF)からのアーカイブ。
  15. ^ 「TechNetダイジェスト認証」2013年8月。
  16. ^ Anthony, Sebastian (2013年2月13日). 「Opera、敗北を認め、GoogleのChromiumに切り替え」. Extreme Tech . Ziff Davis . 2024年1月19日閲覧。
  17. ^ DeLorenzo, Ike (2015年4月3日). 「さようなら、ダイジェストアクセス認証」Bitbucet . 2024年4月23日時点のオリジナルよりアーカイブ。 2025年1月21日閲覧。
  18. ^ "[RFC] HTTPダイジェスト認証の廃止 · Issue #24325 · symfony/symfony". GitHub . 2023年10月12日時点のオリジナルよりアーカイブ。 2025年1月21日閲覧。
  • RFC 7235
  • RFC 6331
  • RFC 2617（RFC 7235により更新）
  • RFC 2069（廃止）
Retrieved from "https://en.wikipedia.org/w/index.php?title=Digest_access_authentication&oldid=1325153915"