Webアプリケーションの場合、サーバーはどの認証方法に従うかを決定しますか、それともクライアントですか。
NTLMやKerberosブラウザなどの認証方法は固有ですか。
イントラネットWebアプリケーションでは、NTLMおよびKerberosと比較して、BASICおよびDigetはどこに位置しますか?
ありがとうございました :)
Webアプリケーションの場合、サーバーはどの認証方法に従うかを決定しますか、それともクライアントですか。
NTLMやKerberosブラウザなどの認証方法は固有ですか。
イントラネットWebアプリケーションでは、NTLMおよびKerberosと比較して、BASICおよびDigetはどこに位置しますか?
ありがとうございました :)
RFC 2617で説明されているように、両者の協力が必要です。
リソースにアクセスするために資格情報が必要な場合、サーバーは、サポートする認証の種類を示す401
1 つ以上のWWW-Authenticate
ヘッダーを含む応答を返します。複数のWWW-Authenticate
ヘッダーがある場合、クライアントは「理解できる最も強力な認証スキームを使用することを選択し、そのチャレンジに基づいて資格情報を要求する必要があります」。
したがって、応答は次のようになります。
WWW-Authenticate: Basic realm="protected area"
WWW-Authenticate: Digest
realm="protected area"
qop="auth"
nonce="ea9c8142787af00ec11bd0eac248cac930"
opaque="cdc069ca3ffe57acff21c259deadbeef"
WWW-Authenticate: Negotiate
これは、サーバーが、 RFC 2617で説明されている Basic および Digest メカニズムと、 RFC 4559で説明されている "SPNEGO" (ネゴシエート メカニズム) を使用する NTLM または Kerberos を受け入れようとしていることを示します。
次に、クライアントはこれらのスキームのどれが最も強力であるかを判断し、リクエストを再度送信する必要があります。これは問題のユーザー エージェント次第ですが、これらのメカニズムは推定される弱さと強さで評価されます (したがって、最も好ましいのはlastです)。
基本はセキュリティを提供しません。クリアテキストのパスワードは簡単に回復できます。セキュリティに対する期待がまったくない場合、またはレイヤがすでに TLS を使用して暗号化されている場合にのみ使用してください。
ダイジェストは、現時点では暗号的に強力であるとは見なされていないハッシュ アルゴリズムに依存するチャレンジ/レスポンス メカニズムです。
NTLMは、最も強力な (NTLMv2) であっても、暗号的に強力ではないハッシュ アルゴリズムに依存するチャレンジ/レスポンス メカニズムのファミリです。ただし、NTLM の利点は、Windows コンピューターのユーザーがログオン時にパスワードをハッシュ化して、パスワードを再入力することなく Web サイトへの「シングル サインオン」を可能にするアルゴリズムへの入力になることです。
Kerberosは、信頼できるキー配布センター (KDC) を使用して安全な認証を提供し、イントラネットには優れた選択肢ですが、インターネット上のすべてのクライアントにとって実行可能なメカニズムになる可能性は低いです。
これらのプロトコルのいずれかの弱点の影響は、トランスポートの暗号化を提供するために TLS でセッションを保護することによって減少させることができ、信頼されていないネットワーク (つまり、インターネット全体) で絶対に実行する必要があります。