WCF サービスへのアクセスが許可されているすべてのユーザー名とそのハッシュ化されたパスワードを含むテーブルがあります。
メッセージ レベルのセキュリティを使用し、暗号化された本文の一部として各要求でユーザー名とパスワードを渡すことに問題はありますか?
これを認証オプションとして提案する人がほとんどいないのはなぜですか?
明確にするために編集します。
ClientCredentials の一部としてすべての要求でユーザー名とパスワードを送信する必要がある証明書でトランスポート セキュリティを使用する場合とは対照的です。
メッセージ レベルのセキュリティが機密性、整合性、および認証を提供する場合、なぜ証明書を使用する方が良い選択肢になるのでしょうか? 資格情報を ClientCredentials で渡すのではなく、暗号化された本文の一部として渡すことの欠点は何ですか?
すべての要求でパスワードを渡すと攻撃が行われ、誰かが送信されたものを読み取ることができます。パスワードを取得すれば、いつでもログインできます。必要に応じて、パスワードを変更することもできます。セッション ID を使用すると、セッションがアクティブである限り、セッションを乗っ取ることができます (パスワードの変更エリアなど、パスワードを再度入力して再確認する必要がある、より保護されたエリアにはアクセスできません)。盗まれたパスワードに対抗するには、パスワードを変更する (そして新しいパスワードを覚えておく) 必要があります。ハイジャックされたセッション ID に対抗するには、セッションを終了するだけです。いずれにせよ、セッション ID を思い出したことはありません。また、パスワードを何度も送信する場合は、常にクライアント アプリケーションのどこかにパスワードを保存する必要があります。それか'
多くの場合、同じパスワードが複数の異なるアプリケーションに使用されるため、ハイジャックされたパスワードは実際にはさらに悪質です。
それに加えて、非常に遅いアルゴリズムを使用してパスワードをハッシュすることがよくあります (これにより、待機する必要があるため、パスワードを推測するのが難しくなります。制限付き試行のようなものを追加することをお勧めします)。辞書攻撃を排除するための時間単位ごとのパスワードそれはあなたの考えとはうまく調和しません。
全体として、パスワードを常に送信するのは悪い考えだと思います。独立しているか、使用されているフレームワークであるかは、クライアント/サーバーアプリケーションの原則です。そして、IDを使ったセッションのようなテクニックがあるので、それを使ってみませんか。常にパスワードを確認するよりも複雑ではありません。
@kratenko の言うとおりです。メッセージごとにパスワードを送信するのはあまり良い方法ではありませんが、暗号化されたメッセージからそのパスワードを取得するのは簡単なことではありません。できることは、WCF 通信で二重のセキュリティを使用することです。これは、メッセージ セキュリティとトランスポート セキュリティ (SSL) を意味します。これを達成する方法を説明するリンクは次のとおりです: http://www.dotnetfunda.com/articles/article891-6-steps-to-implement-dual-security-on-wcf-using-user-name-ssl aspx。
次のような他のオプションもあります。保護されたチャネル (SSL) でユーザー資格情報を 1 回だけ送信し、ユーザー認証の成功に基づいてトークンを生成し、それをクライアントに送り返します。このシナリオでは、それ以降のリクエストで、クライアントはカスタム ヘッダーでそのトークンを提供する必要があります。サービス レベルでは、生成されたトークンを Couchbase などの高性能キャッシュ ストレージ システムに永続化できるため、受信リクエストごとに、クライアントから提供されたトークンとキャッシュからのトークンを比較します。このようにして、サービスをステートレスに維持することができます。この考えが気に入らない場合は、STS (セキュリティ トークン サービス) の使用を選択できます。