ダイジェストアクセス認証

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

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

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

ダイジェスト アクセス認証は、もともとRFC  2069 ( HTTP の拡張: ダイジェスト アクセス認証) で規定されていました。RFC 2069 では、サーバーが生成したnonce 値によってセキュリティが維持される従来のダイジェスト認証スキームを大まかに規定しています。認証応答は次のように形成されます (HA1 と HA2 は文字列変数の名前です)。

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(ユーザー名:レルム:パスワード):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に代わるものとして、「SHA-256」、「SHA-256-sess」、「SHA-512-256」、「SHA-512-256-sess」の4つの新しいアルゴリズムを追加しました。エンコードは「MD5」および「MD5-sess」アルゴリズムと同等で、 MD5ハッシュ関数はSHA-256およびSHA-512-256に置き換えられました。ただし、2021年7月現在、Firefox ^[2]やChrome ^{[3][アップデート]}などの一般的なブラウザはいずれもハッシュ関数としてSHA-256をサポートしていません。2021年10月現在、Firefox 93 ^[4]はダイジェスト認証に「SHA-256」および「SHA-256-sess」アルゴリズムを正式にサポートしています。しかし、「SHA-512-256」、「SHA-512-256-sess」アルゴリズムとユーザー名ハッシュ^[5]のサポートはまだ不足しています。^[6] 2023年8月現在、Chromium 117（当時はChromeとEdge）は「SHA-256」をサポートしています。^{[7][アップデート][アップデート]}

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

HTTP 方式は1993 年にCERNのPhillip Hallam-Bakerによって設計され、 HMAC (keyed-hash message authentication code ) の開発など、その後の認証システムの改善は組み込まれていません。使用されている暗号構造は MD5 ハッシュ関数に基づいていますが、 2004 年には衝突攻撃は平文 (パスワードなど) が不明なアプリケーションには影響しないと一般に考えられていました。^[9]しかし、2006 年の主張^[10]は、他の MD5 アプリケーションにも疑問を投げかけています。

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

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

• パスワードはサーバーにそのまま送信されません。
• パスワードはダイジェストでは直接使用されず、HA1 = MD5(ユーザー名:レルム:パスワード)として使用されます。これにより、一部の実装(例: JBoss ^[11] )では、クリアテキストパスワードではなくHA1を保存できます(ただし、このアプローチの欠点を参照してください)
• クライアントノンスはRFC 2617で導入され、これによりクライアントは、ダイジェスト認証方式を脅かす可能性のあるレインボーテーブルなどの選択平文攻撃を防ぐことができる。
• サーバーの nonce にはタイムスタンプを含めることができます。そのため、サーバーはリプレイ攻撃を防ぐために、クライアントが送信した nonce 属性を検査することがあります。
• サーバーは、再利用を防ぐために、最近発行または使用されたサーバーのノンス値のリストを保持することもできます。
• プレーン パスワードは、正しいサーバーであるかどうかに関係なく、どのサーバーにも送信されないため、フィッシングを防止できます。(公開鍵システムでは、ユーザーが URL が正しいことを確認できることが前提となります。)

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

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

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

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

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

• クライアント証明書を使用した公開鍵認証 (通常はHTTPS / SSL クライアント証明書で実装されます)。
• KerberosまたはSPNEGO認証。たとえば、統合 Windows 認証(IWA)用に構成されたMicrosoft IISで実行されます。
• セキュア リモート パスワード プロトコル( HTTPS / TLSレイヤー内が望ましい)。ただし、これは主流のブラウザーでは実装されていません。
• JSON Web Token (JWT) は、いくつかのクレームをアサートするアクセス トークンを作成するためのJSONベースの標準 RFC 7519です。

以下の例は元々 RFC 2617 で示されていたものですが、ここでは各リクエストとレスポンスに期待される全文を示すために拡張されています。「auth」(認証) 品質保護コードのみがカバーされていることに注意してください。2005 年 4 月現在^{[アップデート]}、「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

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

サーバー応答

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
日付: 日曜日、2005 年 4 月 10 日 20:27:03 GMT
コンテンツ タイプ:  text/html
コンテンツの長さ:  7984

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

「応答」値は、次の 3 つの手順で計算されます。値が結合される場合は、コロンで区切られます。

1. ユーザー名、認証領域、パスワードを組み合わせた MD5 ハッシュが計算されます。結果は HA1 と呼ばれます。
2. メソッドとダイジェストURI を組み合わせた MD5 ハッシュが計算されます (例: および"GET") "/dir/index.html"。結果は HA2 と呼ばれます。
3. HA1 結果、サーバー nonce (nonce)、リクエスト カウンター (nc)、クライアント nonce (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 で再送信する必要があることを示す必要があります。

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

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

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

htdigestコマンドの構文: ^[14]

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

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

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

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

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

• アマヤ
• Geckoベース: (auth-int ^[15]は含まない)
  • Mozilla アプリケーション スイート
  • モジラファイアフォックス
  • ネットスケープ7以上
• iCab 3.0.3 以上
• KHTMLおよびWebKitベース: (auth-int ^[16]は除く)
  • アイキャブ4
  • コンカラー
  • グーグルクローム
  • サファリ
• タスマンを拠点とする:
  • Mac 用インターネット エクスプローラー
• Tridentベース:
  • Internet Explorer 5+ ^[17] (auth-intは含まない)
• Prestoベース:
  • Opera（Operaは2013年にPrestoから切り替えた）^[18]
  • Opera モバイル
  • オペラミニ
  • ニンテンドーDSブラウザ
  • Nokia 770ブラウザ
  • Sony Mylo 1のブラウザ
  • Wii インターネット チャンネル ブラウザー

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

• ビットバケット: https://bitbucket.org/blog/fare-thee-well-digest-access-authentication
• Symfony PHP フレームワーク: https://github.com/symfony/symfony/issues/24325

• AKA (セキュリティ)
• JSON ウェブトークン(JWT)
• 基本アクセス認証
• HTTP+HTML フォームベース認証

• RFC7235 の翻訳
• RFC 6331
• RFC 2617 (RFC 7235 により更新)
• RFC 2069 (廃止)