Webサービスに渡される資格情報の保護
分散アーキテクチャで使用するシングルサインオンシステムを設計しようとしています。具体的には、クライアントのWebサイト（つまり、別のドメイン/サーバー/ネットワーク上のWebサイト）がユーザーが私の中央システムにアカウントを登録できるようにする方法を提供する必要があります。
したがって、ユーザーがクライアントのWebサイトでアクションを実行し、そのアクションがアカウントを必要とすると見なされた場合、クライアントはユーザーがメールを提供して新しいアカウントに登録できるページ（サイト/ドメイン上）を生成します。パスワード。
次に、クライアントはこの情報をWebサービスに送信する必要があります。Webサービスはアカウントを登録し、セッショントークンタイプの値を返します。
クライアントはパスワードをネットワーク経由で送信する前にハッシュする必要があり、ウェブサービスはhttpsを必要としますが、これは十分に安全であるとは思われず、可能な限り最も安全な方法でこれを実装する方法についてアドバイスが必要です。
他のいくつかの関連情報：
- 理想的には、クライアントとコードを共有しない方がよい
- ユーザーをWebサービスと同じサーバー上の安全なページにリダイレクトすることを検討しましたが、これは非技術的な理由で拒否される可能性があります。
- ほとんどの場合、ハッシュして渡す前にパスワードをソルトする必要がありますが、クライアントはa）ソルトを生成してそれを私たちに伝えるか、b）来てソルトを要求する必要があります-どちらも汚い感じです。
ヘルプやアドバイスをいただければ幸いです。
正確には何が必要ですか？真ん中の人がパスワードを読み取らないようにするには？真ん中の男がログオンできないようにするために？
途中の男がパスワードを読み取れないようにしたい場合は、それらのパスワードをハッシュ化してください。それはそれと同じくらい簡単です。
途中の男性がユーザー名を取得するのを避けたい場合もあります。ここでは、ハッシュだけを送信することはできませんが、サーバーが復号化のための秘密鍵を持っている場合、クライアントに送信される公開鍵でユーザー名とパスワードのペアを暗号化できます。
途中の男がログオンできないようにする場合は、タスクが少し複雑になります。公開/秘密鍵は引き続き使用できますが、次のようになります。
公開鍵は、事前にWebサービスのコンシューマに通信する必要があります（同じ鍵ペアを何度も何度も使用するという難点があります。また、他のチャネルが秘密鍵を送信するのが難しいため、ミドルはそれをキャッチすることはできません）、
または、Webサービスのコンシューマーは、サーバーが応答で自身の公開鍵を暗号化するのに役立つ2番目の公開鍵を送信できます。
- クライアント側SSL（公開鍵）証明書は、中間者攻撃からクライアントを保護する唯一のスキームであり、クライアントを最も安全にします。 Edit前回確認したところ、Verisignはクライアント証明書ごとに$ 100-200を費やしていましたEnd-Edit。クライアントが人間の場合は、証明書をブラウザにインストールして、いつでも別のブラウザに移動できます。これは、より安全で、広く受け入れられているCookieに少し似ています。 OpenSSLマニュアルを読んだ場合、OpenSSLを使用して 独自の認証局になり、独自の証明書を生成して受け入れる ですが、すべてを正しく行うように細心の注意を払う必要があります（間違いはセキュリティを損なう可能性があります）ニュースで繰り返し見られるシステムの）。私が最後にチェックしたとき、Chromeはユーザーにコマンドラインを使用してクライアント証明書を設定するように要求しましたが、他のすべての一般的な最新のブラウザーはJavaScriptを介して証明書を設定できました。
- クライアント側のCookie。クライアントは現在と同じようにログインしますが、サーバーは暗号化されたCookieを送信します（サーバーはすべてのハッシュとソルトを行い、ハッシュとソルトするデータを選択します）。ほとんどの人はこの方法を使用します。おそらく実装が簡単だからです。 Webサイトのログインページに[ログインしたままにする]チェックボックスが表示された場合、通常これが原因です。
- OpenID には、利用可能な完全なドキュメントと実装があります。 1つのアカウント（OpenIDが有効になっている）を利用して、多くの場所にログインできます。これには、ユーザーが1つのパスワードを「覚える」だけでよいという利点があります（Wordはパスワードを「覚えて」いないのが嫌いです。人々はパスワードマネージャを使用して、覚えていないパスワードを保存する必要があります）。これの大きな欠点は、誰かがマスターアカウントを危険にさらした場合、接続されているすべてのアカウントがそのマスターアカウントに陥ることです。
- ActiveDirectory/LDAPこれは、企業内の内部アプリケーション用の最も一般的で伝統的なシングルサインオンの形式です。名前と電話番号のアドレス帳（LDAPの「ディレクトリ」）の管理が大いに考慮されたときに、それはNovelによって作成されたと思います。これは、コンピュータのセキュリティが考慮される前の時代でした。 MicrosoftのActive Directory実装は、10年以上にわたってすべての主要なオペレーティングシステムとともに出荷されています。デスクトップにサインインするだけで、AD/LDAP対応のイントラネットサイトに自動的にサインインできます。すべてのクライアントが同じローカルネットワーク上にあるか、少なくともAD/LDAPサーバーが資格情報をチェックするWebサーバーにアクセスできる必要があります。それ自体はセキュリティを提供しないか、本当に悪いセキュリティを提供します。認証パケットがトランスポート層（ssl over https）によって暗号化されていることを絶対にテストし、暗号化されていない接続を受け入れないことをサーバーでテストする必要があります。人々のデスクトップログイン情報をネットワーク経由でプレーンテキストで自由に送信するという考えは、本当に不快です。この弱点は何年にもわたって何度も悪用されてきたと言うために、「エクスプロイト」という言葉をほぼ安くしています。あなたがこのルートをたどれば、LDAPクライアントはLinuxとMacだけでなくWindowsでも利用できると思います。
OAuth を調べてください。これは、この「何かを実行するための権限」の役割用に設計されています。ユーザーIDを要求するのではなく、ユーザーに、信頼できるトークンを提供して、そのユーザーに与える許可を決定するために使用できるトークンを提供するよう依頼します。
すべてのセキュリティ暗号化グビンはフレームワークで処理されるので、そのようなフレームワークを使用して通信を暗号化する方法についてあまり心配する必要はありません。