主要なサイト（Facebook、Googleなど）でハッシュ化されていないパスワードが送信されるのはなぜですか？
クイックサマリー：
現代のウェブサイトは、セキュリティ上の理由から、元のパスワードの漏えいを防ぐために、サーバーに送信する前にすべてのクライアントが独自のパスワードをハッシュする必要があります（異なるサイト間で再利用される可能性が高い）また、単一のSSLキーを単に復号化するのではなく、個別に復号化を必要とする場合。
元の質問：
確認するために簡単なチェックを行ったところ、SSL/TLSを使用しているにもかかわらず、主要なWebサイトがログイン用の元の形式でパスワードを送信しているように見えて驚いたそれらをデータベースに入れる前に、それらをハッシュしてソルト/ペッパーしていることを理解しています。ただし、それでも問題が発生します。
パスワードを送信する前に、クライアント側でサイト固有のソルトを使用してすべてのパスワードをハッシュし、特に 最近のニュース を考慮すると、ハッシュをハッシュする方がクライアントにとって実質的により安全になるようです。
NSAとその同盟国は日常的にそのような接続を数百万人ずつ傍受しています。NSAのドキュメントによると、代理店は1,000万本の傍受したhttps接続をクラックすることを意図していました。 インテリジェンスサービスは、ユーザーが自分のパスワードを入力した瞬間に特に関心があります。2012年末までに、システムは各インスタンスで「少なくとも100個のパスワードベースの暗号化アプリケーションの存在を検出する」ことが月に約20,000回できると想定されていました（エンファシスを追加）
効率の観点からは、クライアントがパスワードをハッシュする必要はないことを理解していますが、元のパスワードをハッシュすることは、データがサーバー上で傍受された場合でも、事前にハッシュされているという事実にもっと興味がありますまたは、接続中にSSLを復号化すると、傍受されたWebサイトにログインする場合にのみ役立ちます。
多くの人がパスワードを再利用する人 を考慮した場合、これは大きな懸念事項になるはずですが、これらの大規模なサイトはまだ元のパスワードを送信し、ハッシュ化しています。これの背後に技術的な理由がありますか、それとも理想的には変更する必要があるのは古い慣習だけですか？
明確化のための編集：これらのサイトがクライアント側ですべてのハッシュ化を開始し、そのままDBにそのまま投入することはお勧めしません。ハッシュを確実にハッシュ/ソルトする必要があります。私の提案では、クライアントはパスワードをハッシュして、サーバーが元のデータを知らないようにします。そのため、同じパスワードを再利用でき、1つのWebサイトでの侵害が他のサイトでのパスワードの侵害を意味するわけではありません。素晴らしいボーナスとして、悪意のあるプロキシによって発見された、パスワードを渡すのではなく、ログインしたサイトへのアクセスも制限されます。
次の2つのシナリオを区別する必要があります。
1）断固としたハッカーがパスワードを取得しようとします
この状況では、SSLは通常十分な保護を提供します。適切に実装されたSSLを破ることは非常に困難です。攻撃者がManInTheMiddle攻撃を開始できるとすぐに、攻撃者はハッシュを計算している（JS）スクリプトを簡単に削除できるため、クライアント側のハッシュはそれ以上保護されません。
2）自動攻撃が開始されます
SSLトラフィックを読み取ることができる組織がある場合、クライアント側のハッシュを計算するとコストが増加します。これは、自動化された攻撃ではパスワードのハッシュしか表示されないためです。サイトへの関心が十分に高まるとすぐに、彼らはこのサイトのスクリプトを自動的に削除するコードを書くことができます。
ハッシュしか持っていない場合でも、このハッシュをブルートフォースにしようとする可能性があります。おそらく高速ハッシュクライアントサイド（SHA *）を使用するため、ブルートフォースは比較的簡単です。 JSのような遅いクライアント側言語では、遅いハッシュ（PBKDF2またはBCrypt）を使用することは実装が困難です。クライアント側で遅いハッシュを計算する場合でも、ユーザーを長く待たせたくないので、サーバー側の時間を短縮する必要がありました。サーバー側のハッシングはクライアント側のハッシングよりも高速に（ラウンド数が多く）実行できるため、サーバー側のハッシングとクライアント側のハッシングを交換するとセキュリティが低下します。
➽これは、彼らの人生をより困難にすることができるが、彼らの関心が十分に大きい場合、彼らを止めることができないことを意味します。ユーザーがセキュリティを意識し、非常に強力なパスワードを選択した場合、クライアント側のハッシュが役立つ可能性がありますが、このユーザーはおそらくパスワードを再利用しません。