4. セキュリティに関する考慮事項 (Security Considerations)
4.1 基本認証を使用したクライアント認証 (Authentication of Clients using Basic Authentication)
基本認証方式 (Basic Authentication Scheme) は安全なユーザー認証方法ではなく、物理ネットワーク上で平文として送信されるエンティティを何ら保護しません。HTTPは、セキュリティを向上させるため、または基本認証に拡張機能（ワンタイムパスワードを使用する方式など）を追加するために、追加の認証方式および暗号化メカニズムを使用することを妨げません。
基本認証の最も深刻な欠陥は、本質的に平文でのユーザーパスワードの物理ネットワーク上での伝送をもたらすことです。ダイジェスト認証 (Digest Authentication) が対処しようとしているのは、まさにこの問題です。
基本認証はパスワードの平文送信を伴うため、（拡張機能なしで）機密情報や貴重な情報を保護するために使用すべきではありません (SHOULD NOT)。
基本認証の一般的な使用法は識別目的です――ユーザーにユーザー名とパスワードを識別手段として提供することを要求することです。例えば、サーバー上で正確な使用統計を収集する目的などです。この方法で使用される場合、保護されたドキュメントへの不正アクセスが主要な懸念事項でなければ、使用に危険はないと考えたくなります。これは、サーバーがユーザー名とパスワードの両方をユーザーに発行し、特にユーザーが自分のパスワードを選択することを許可しない場合にのみ正しいです。危険は、ナイーブなユーザーが複数のパスワードを維持するタスクを避けるために、単一のパスワードを頻繁に再利用することです。
サーバーがユーザーに自分のパスワードを選択させる場合、脅威はサーバー上のドキュメントへの不正アクセスだけでなく、ユーザーが同じパスワードで保護している他のシステム上の他のリソースへの不正アクセスでもあります。さらに、サーバーのパスワードデータベースでは、多くのパスワードが他のサイトでのユーザーのパスワードである可能性もあります。したがって、この情報が安全な方法で維持されていない場合、そのようなシステムの所有者または管理者は、システムのすべてのユーザーを、それらすべての他のサイトへの不正アクセスのリスクにさらす可能性があります。
基本認証は、偽装サーバーによるなりすましにも脆弱です。ユーザーが基本認証で保護された情報を含むホストに接続していると信じ込まされているが、実際には敵対的なサーバーまたはゲートウェイに接続している場合、攻撃者はパスワードを要求し、後で使用するために保存し、エラーを装うことができます。このタイプの攻撃はダイジェスト認証では不可能です。サーバー実装者は、ゲートウェイまたはCGIスクリプトによるこの種の偽装の可能性に対して保護すべきです (SHOULD)。
4.2 ダイジェスト認証を使用したクライアント認証 (Authentication of Clients using Digest Authentication)
ダイジェスト認証 (Digest Authentication) は、公開鍵ベースのメカニズムと比較すると、強力な認証メカニズムを提供しません。
しかし、これはLDAP [10]、POPおよびIMAP（RFC 2195 [9] を参照）での使用が提案されている（例えば）CRAM-MD5よりも著しく強力です。これは、はるかに弱く、さらに危険な基本メカニズムを置き換えることを意図しています。
ダイジェスト認証は、実際のパスワードを保護する以外の機密保護を提供しません。リクエストとレスポンスの残りの部分はすべて盗聴者が利用できます。
ダイジェスト認証は、どちらの方向のメッセージに対しても限定的な完全性保護のみを提供します。qop=auth-intメカニズムが使用される場合、WWW-AuthenticateおよびAuthorizationヘッダーフィールドのresponse指令値の計算に使用されるメッセージ部分（上記のセクション3.2を参照）が保護されます。ほとんどのヘッダーフィールドとその値は、中間者攻撃の一部として変更される可能性があります。
ダイジェスト認証は、多くの安全なHTTPトランザクションのニーズを満たすことができません。これらのニーズには、TLSまたはSHTTPがより適切なプロトコルです。特に、ダイジェスト認証は、機密保護が必要なトランザクションには使用できません。それにもかかわらず、ダイジェスト認証は多くの機能にとって有用かつ適切です。現在基本認証を使用しているサービスは、できるだけ早くダイジェスト認証に切り替えるべきです。
4.3 限定使用のNonce値 (Limited Use Nonce Values)
ダイジェスト方式は、request-digest値の生成をシードするためにサーバー指定のnonceを使用します（上記のセクション3.2.2.1で指定されているとおり）。セクション3.2.1のnonceの例に示されているように、サーバーはnonceを自由に構築でき、特定のクライアント、特定のリソース、限定された期間または使用回数、またはその他の制限からのみ使用できるようにできます。これにより、例えばリプレイ攻撃（4.5を参照）に対して提供される保護が強化されます。ただし、nonceの生成と検証のために選択された方法には、パフォーマンスとリソースの影響もあることに注意すべきです。
4.4 ダイジェスト認証と基本認証の比較 (Comparison of Digest with Basic Authentication)
ダイジェスト認証と基本認証の両方とも、決意した敵による不正アクセスを防げないという意味で弱いです。しかし、両者の比較は、基本認証をダイジェスト認証に置き換える有用性、そしておそらく必要性さえも指摘しています。
このプロトコルが使用される可能性のあるトランザクションのタイプにとって、最大の脅威はネットワーク盗聴です。このタイプのトランザクションには、例えば、有料購読者に使用が制限されているデータベースへのオンラインアクセスが含まれる場合があります。基本認証では、盗聴者はユーザーのパスワードを取得できます。これにより、彼はデータベース内の何にでもアクセスできるだけでなく、さらに悪いことに、ユーザーが同じパスワードで保護している他のものへのアクセスも許可されます。
対照的に、ダイジェスト認証では、盗聴者は問題のトランザクションのみにアクセスでき、ユーザーのパスワードにはアクセスできません。盗聴者が得た情報はリプレイ攻撃を許可しますが、同じドキュメントリクエストでのみであり、それでさえサーバーのnonce選択によって制限される可能性があります。
4.5 リプレイ攻撃 (Replay Attacks)
ダイジェスト認証によるリプレイ攻撃は、単純なGETリクエストに対しては通常無意味です。なぜなら、盗聴者はリプレイによって取得できる唯一のドキュメントをすでに見ているからです。これは、要求されたドキュメントのURIがクライアントリクエストでダイジェストされ、サーバーはそのドキュメントのみを配信するためです。対照的に、基本認証では、盗聴者がユーザーのパスワードを持っていると、そのパスワードで保護されているあらゆるドキュメントが彼に開かれます。
したがって、いくつかの目的では、リプレイ攻撃から保護する必要があります。優れたダイジェスト実装は、さまざまな方法でそれを行うことができます。サーバーが作成する「nonce」値は実装依存ですが、クライアントIP、タイムスタンプ、リソースETag、およびプライベートサーバーキーのダイジェストが含まれている場合（上記で推奨されているように）、リプレイ攻撃は単純ではありません。
リプレイ攻撃の可能性さえも許容できないアプリケーションの場合、サーバーは2回目に受け入れられないワンタイムnonce値を使用できます。これには、nonceタイムスタンプが期限切れになるまで、どのnonce値が使用されたかをサーバーが記憶するというオーバーヘッドが必要です。
4.6 複数の認証方式によって生じる弱点 (Weakness Created by Multiple Authentication Schemes)
サーバーがWWW-Authenticateヘッダーで複数の認証方式を提供する場合、クライアントはサポートする最強の方式を選択すべきです (SHOULD)。ただし、攻撃者がレスポンスを変更して強力な方式を削除できる場合、クライアントは弱い方式の使用を強制される可能性があります。
4.7 オンライン辞書攻撃 (Online dictionary attacks)
サーバーが認証試行の速度を制限しない場合、攻撃者は正しいパスワードを推測するために多数のパスワードを試すことができます。サーバーは、単一のIPアドレスからの失敗した認証試行の速度を制限すべきです (SHOULD)。
4.8 中間者攻撃 (Man in the Middle)
ダイジェスト認証は中間者攻撃に対して脆弱です。攻撃者は、クライアントとサーバー間の通信を傍受し、メッセージを変更または置換できます。TLSまたは他のトランスポート層セキュリティメカニズムを使用することで、このような攻撃を防ぐことができます。
4.9 選択平文攻撃 (Chosen plaintext attacks)
ダイジェスト認証は選択平文攻撃に対して脆弱です。攻撃者は特定のURIを選択し、結果として得られるダイジェストを観察することで、パスワードに関する情報を潜在的に得ることができます。
4.10 事前計算された辞書攻撃 (Precomputed dictionary attacks)
攻撃者がサーバーのパスワードファイルにアクセスできる場合、一般的なパスワードのダイジェストを事前計算し、これらのダイジェストをファイル内のダイジェストと比較できます。ソルト値 (Salt) を使用することで、この攻撃をより困難にすることができます。
4.11 バッチブルートフォース攻撃 (Batch brute force attacks)
攻撃者が複数の認証交換をキャプチャできる場合、オフラインでパスワードをブルートフォースしようと試みることができます。強力なパスワードの使用とnonceの有効期間の制限により、このリスクを軽減できます。
4.12 偽装サーバーによるなりすまし (Spoofing by Counterfeit Servers)
クライアントは、偽装サーバーへの接続を防ぐために、サーバーの身元を検証すべきです (SHOULD)。サーバー証明書検証を伴うTLSの使用により、このような攻撃を防ぐことができます。
4.13 パスワードの保存 (Storing passwords)
サーバーは平文でパスワードを保存すべきではありません (SHOULD NOT)。代わりに、パスワードのハッシュ値を保存すべきです。ダイジェスト認証の場合、サーバーはH(username:realm:password)を保存でき、これにより平文パスワードを保存せずにクライアントを検証できます。
4.14 まとめ (Summary)
ダイジェスト認証は基本認証よりも優れたセキュリティを提供しますが、完全なセキュリティソリューションではありません。強力なセキュリティを必要とするアプリケーションには、TLSまたは他のより強力なセキュリティメカニズムを使用すべきです。それにもかかわらず、ダイジェスト認証は多くのアプリケーションにとって実用的で有用な改善です。