4. セキュリティに関する考慮事項
Basic 認証スキームは安全なユーザー認証方法ではなく、キャリアとして使用される物理ネットワーク上で平文で送信されるエンティティを何ら保護しません。HTTP は、Basic 認証への拡張 (ワンタイムパスワードを使用するスキームなど) の追加を妨げません。
Basic 認証の最も深刻な欠陥は、ユーザーのパスワードが物理ネットワーク上で平文送信されることです。他の多くの認証スキームはこの問題に対処しています。
Basic 認証は平文でのパスワード送信を伴うため、機密情報や価値ある情報を保護するために (HTTPS [RFC2818] などの拡張なしに) 使用すべきではありません (SHOULD NOT)。
Basic 認証の一般的な使用法は識別目的です —— サーバー上で正確な使用統計を収集するなどの目的で、ユーザーにユーザー ID とパスワードを識別手段として提供することを要求します。この方法で使用される場合、保護されたドキュメントへの不正アクセスが主要な懸念事項でなければ、その使用に危険はないと考えたくなります。これは、サーバーがユーザー ID とパスワードの両方をユーザーに発行し、特にユーザーが自分のパスワードを選択することを許可しない場合にのみ正しいです。危険は、単純なユーザーが複数のパスワードを維持するタスクを避けるために、頻繁に単一のパスワードを再利用することから生じます。
サーバーがユーザーに自分のパスワードを選択させる場合、脅威はサーバー上のドキュメントへの不正アクセスだけでなく、ユーザーが同じパスワードで保護している他のシステム上の他のリソースへの不正アクセスでもあります。さらに、サーバーのパスワードデータベースでは、多くのパスワードが他のサイトのユーザーのパスワードでもある可能性があります。したがって、そのようなシステムの所有者または管理者は、この情報が安全な方法で維持されていない場合、システムのすべてのユーザーを他のすべてのサイトへの不正アクセスのリスクにさらす可能性があります。これは、セキュリティとプライバシーの両方の懸念を引き起こします ([RFC6973])。同じユーザー ID とパスワードの組み合わせが電子メールや健康ポータルアカウントなどの他のアカウントへのアクセスに使用されている場合、個人情報が露出される可能性があります。
Basic 認証は、偽装サーバーによるなりすましにも脆弱です。ユーザーが、実際には敵対的なサーバーまたはゲートウェイに接続しているにもかかわらず、Basic 認証によって保護された情報を含むホストに接続していると信じ込まされた場合、攻撃者はパスワードを要求し、後で使用するために保存し、エラーを装うことができます。サーバー実装者はこの種の偽装から保護すべきです。特に、既存の接続でメッセージフレーミングの制御を引き継ぐことができるソフトウェアコンポーネントは、慎重に使用するか、まったく使用しないようにする必要があります (例えば: [RFC3875] の第 5 節で説明されている NPH ("Non-Parsed Header") スクリプト)。
Basic 認証を実装するサーバーとプロキシは、リクエストを認証するために、何らかの形式でユーザーパスワードを保存する必要があります。これらのパスワードは、パスワードデータが漏洩しても簡単に回復できないような方法で保存されるべきです。これは、ユーザーが自分のパスワードを設定することが許可されている場合に特に重要です。ユーザーは弱いパスワードを選択し、認証レルム間で再利用することが知られているためです。優れたパスワードハッシュ技術の完全な議論はこの文書の範囲を超えていますが、サーバー運営者はパスワードデータ漏洩の場合にユーザーへのリスクを最小限に抑える努力をすべきです。たとえば、サーバーは平文またはソルトなしダイジェストとしてユーザーパスワードを保存することを避けるべきです。最新のパスワードハッシュ技術に関する詳細な議論については、"Password Hashing Competition" (https://password-hashing.net) を参照してください。
UTF-8 文字エンコーディング方式と正規化の使用は、追加のセキュリティ考慮事項をもたらします。詳細については、[RFC3629] の第 10 節と [RFC5198] の第 6 節を参照してください。