ハッシュ、ソルト、ベストプラクティス
ハッシング、ソルト、ペッパーについて読んでいると、次のシナリオを理解できません。
Webアプリケーションがあり、そのサイトに登録する場合、クライアント側またはサーバー側でパスワードをハッシュ化する必要がありますか？クライアント側でハッシュすることを検討する場合は、個別のソルトを生成してパスワードに追加し、その組み合わせをハッシュして、ソルトとともにサーバーに送信する必要がありますorパスワードをハッシュしてサーバーに送信すると、ソルトはサーバーによってハッシュに追加され、ハッシュされます。しかし、攻撃者がログイン中にクライアントとサーバー間の接続を傍受できる場合、クライアントはハッシュされた（またはクリアテキスト）パスワードをサーバーに送信するだけなので、ソルトには興味がありません...そして、攻撃者が破ることができる場合データベースに入れても、ハッシュをブルートフォースすることができます。私の知る限り、ソルトはRainbowTable攻撃に対してのみ有効です（？）
次に、ベストプラクティスは何ですか？誰がパスワードをハッシュし、どこにソルトを追加する必要がありますか？
一般的に言って、ソルトとハッシュはクライアント側ではなくサーバー側で行われます。サーバーとクライアント間の通信は、暗号化（TLS）で保護する必要があります。 Andersがコメントで言及しているように、これはあなたの多くの質問に答えるかもしれません： HTTPS Webアプリケーションの場合、POSTする前にパスワードを暗号化して、MITM攻撃者がパスワードを悪用しないようにすることは価値がありますか？
一般的にソルトとハッシュについて：ソルトとハッシュの背後にある考え方は、攻撃者にブルートフォースアルゴリズムを実行するように強制することになります。これは、（a）ネットワークを保護してユーザーパスワードを変更するためのサービス時間を購入し、（b）会社/ウェブサイト内の悪意のあるユーザーがユーザーのパスワードを取得するのを防ぎます（他のサイトでそのパスワードを試すなどのいたずらなことのため）。
塩は多くのことを行います。 （1）言ったようにレインボーテーブル攻撃から保護します、（2）データ侵害の場合、バニラハッシュよりもパスワードクラッキングを困難にします（つまり、攻撃者がすべてのハッシュのデータベースを構築することはできません。アルゴリズム;everyハッシュ用のデータベースが必要ですが、これは実行できません）;これにより、サイトとユーザーがアルゴリズムとパスワードを変更する時間が確保され、（3）サイトで働いている人がユーザーのパスワードを簡単に盗むことができなくなり、（4）認証プロセスを保護するためのより多くのアーキテクチャオプションが許可されます。
（4）について1分間話してみると、（非常に大規模な国際的な）私のクライアントにはマイクロサービスアーキテクチャがあり、その認証プロセスは多くのソルト（ユーザー名に基づく）の1つでパスワードをハッシュすることで機能しました before実際のデータベースをチェックしたマイクロサービスに送信します。このタイプの分離により、データベースを処理するコードがソルトとパスワードの両方を知ることができなくなり、ソルトがハッシュを保持しない（メモリ内でもディスク上でも）ことを認識していたマイクロサービスがなくなりました。攻撃者はデータベースダンプを使用することはできません。データベースとソフトウェアが複数のサーバーから必要です。盗まれたデータベースがデータベースをハッシュすることに近づかないため、これにより複雑さが増します。また、（別のサーバーからの）ソルトのリストも必要です。従業員は両方のサーバーにアクセスできず、（3）に役立ちました。
クライアント側のハッシュがあまり役に立たない理由：中間者攻撃は、クライアントとサーバーの間で送信されるすべてのものをキャプチャできます。送信する前にパスワードをハッシュしてもほとんど意味がありません。攻撃者はハッシュを生成できる必要はありません。アクセスするには、まったく同じ要求をもう一度送信する必要があります。
たとえば、次のリクエストとパラメータを見てみましょう（読みやすさのために実際のHTTPヘッダーは使用していません）。
POST /auth/login
[email protected]
pass=mypassword
対：
POST /auth/login
[email protected]
pass=89e01536ac207279409d4de1e5253e01f4a1769e696db0d6062ca9b8f56767c8
サーバーはハッシュによって実際のパスワードが「mypassword」であることを認識できないため、ハッシュをそのまま使用してユーザーのアカウントを確認します。そのリクエストを読み取ることができる攻撃者は、パスワードが「mypassword」であることを知る必要はありません。ハッシュを取得する必要があるだけです。これはアカウントを保護しません。これが防ぐonlyことは、攻撃者が他のサイトでパスワードをテストできることです（たとえば、多くの人がGoogleと銀行に同じメールとパスワードを愚かに使用しています）。