私は何かがあるので、私は尋ねることにしました。 ASP.NETアイデンティティセーフでのデフォルト登録（デフォルトのASP.NET MVCプロジェクトなど）ですか？私は、デフォルトでは、私たちはサーバーに純粋なパスワードを送信することを意味し、それは誰かがキャッチすることは可能ですか？それを改善するために私は何ができますか？私はいくつかの記事を読みましたが、私が気づいたのは、クライアント側のハッシングがサーバ上と同じくらい良い点であり、ポイントがないことです。サーバーに登録するセキュリティ
SSLエンドポイントに送信されたトラフィックを暗号化して送信クレデンシャルはクリアテキストです。これにより、トラフィックが傍受される可能性のある中間者攻撃のリスクが軽減されます。有効なドメインとこのドメインの有効なSSL証明書を持っていれば、それを使ってトラフィックを暗号化すれば、傍受されたトラフィックを復号化してクレデンシャルを公開するリスクを軽減できます。
これは、ログインエンドポイントをSSLで保護するだけでなく、多くの人がこれが十分だと信じています。セッションが確立されると、別の可能性のある攻撃ベクトルが認証クッキーであるため、すべてのトラフィックを暗号化する必要があります。このcookieはman-in-the-middleでも傍受される可能性があるので、安全で暗号化されたチャネルを経由するように、secureフラグが付いていることを確認する必要があります。
今後のHTTP 2/SPDYプロトコルでは、すべてがHTTPSで暗号化されているため、これらのセキュリティ問題は軽減されます。
これはサーバーの実装ではなく、使用している接続です。 HTTPSログインページ（ログイン後だけでなく）では、あなたは嫌です（皮肉なことを意図しています）。 HTTPを使用すると、_man-in-the-middle_があなたの資格情報を盗んでしまう可能性があります。 BTWハッシングクライアント側はセキュリティを向上させません（この場合）。とにかくトピックはかなり広大です... –
HTTPSはそれを安全にしますか？まだパスワードをキャッチする可能性はありますか？ – Koteczeg
はい、いいえ。それは安全ですが、サーバであると主張する真ん中の誰かが依然としてすべてのクライアント要求を取得してから、クライアントであると思われるサーバにルーティングします。もちろん、クライアントは証明書が破損しているため、これを検出できます（ただし、これを確認するのはクライアントのユーザ責任です）。これを強制する場合は、各クライアントに証明書を渡す必要があります（サーバーもクライアントを検証します）。このトピックについては、security.stackexchangeをご覧ください。 –