露出したsaltワードを使用したクライアント側のパスワードハッシュ-違反は見つかりましたか？
ログインインターフェイスのあるソフトウェアをダウンロードしました。これは月額100ドルのサブスクリプションソフトウェアです。
私はソフトウェアを逆アセンブルし、パスワードがソースコードで誰もが見ることができるハードコーディングされた「塩」と組み合わせて送信されていることを発見しました（MD5で暗号化し、ハッシュをサーバーに送信します。
I 希望すべてのユーザーに固有のソルトを使用して、サーバー側でパスワードが再度暗号化されることを確認しますが、たとえそうであっても、これは違反ではありませんか？攻撃者はパスワードを簡単に盗聴したり、ハッシュ送信攻撃を行ったりすることはできませんか？
場合によります。質問に特定の答えを与えるのに十分な情報がありません。おそらくサーバー側を知らなければ、評価するのは難しいでしょう。
これは違反ではありませんか？
クライアントがパスワードをハッシュしているという事実を知っているだけでは、このアカウントや他のアカウントに関する機密情報が明らかにならないので、私はまだそれを違反とは呼びません。
攻撃者がパスワードを簡単に盗聴したり、ハッシュ送信攻撃を行ったりすることはできませんか？
攻撃者がクライアントとサーバー間の通信を傍受できたとしても、元のパスワードが送信されるか、それのハッシュバージョンであるかに関わらず、違いはありません。どちらの場合も、攻撃者は必要な資格情報を持っています。それらを今止めることができる唯一のものは二要素認証でしょう。
スニッフィングを再度行うのに最適なのは、通信にHTTPSを適用することです。
誰にとっても同じである場合、それは本当に「塩」ですか？
いいえ、 salt は、ストレージ内のパスワードを保護するために一方向ハッシュ関数に追加されるランダムデータです。ソルトはランダムで、パスワードごとに一意である必要があり、可能なすべてのソルトの組み合わせでレインボーテーブルを再度作成するのに十分な長さでなければなりません。
コショウは秘密にされなければならないので、それはまた pepper ではありません。
そもそもなぜクライアント側でパスワードをハッシュするのですか？
パスワードをサーバーに送信する前にクライアント側でハッシュすると、結果のハッシュが新しいパスワードに変換されます。認証プロセス中に追加のセキュリティは提供しませんが、ユーザーのパスワードを一般的に保護します（特にユーザーが他の場所でも使用する場合）。クリアテキストのパスワードはサーバーによって送信または処理されることはありません。 （データベースとは対照的に）サーバーが危険にさらされている場合、元のパスワードを抽出することはより困難になります。
PS： ハッシュ md5やshaなどのハッシュ関数を使用したものは、暗号化とは異なります。暗号化されたデータは復号化できますが、ハッシュされたデータは復元できません。ハッシュは一方向の関数だからです。
これは違反ではありません。
侵害は、誰かが本来持つべきではないデータにアクセスできるようになったときに発生します。認証プロセスに関するいくつかの（合法的に懸念される）詳細を発見しましたが、機密の顧客データは明らかにしていません。
攻撃者があなたが暗示するほど簡単にこれを利用することもできません。攻撃者は確かにトラフィックを盗聴し、ハッシュを知っているため、表示されるパスワードを解読する可能性があります。ただし、一般的に、彼らが盗聴できる唯一のパスワードは、自分のマシンから出てくるものです。おそらく彼らはとにかくそれらをすでに知っていたのでしょう。
攻撃者が実際にハッシュされたパスワード（または他の機密データ）を盗んだ場合にのみ、侵害が発生します。その時点で、一定のソルトは攻撃者の生活を容易にします。ソルトを使用して一般的に使用されるパスワードのハッシュのレインボーテーブルを事前に生成し（MD5を使用しているので非常に簡単です）、その後潜在的にデータが実際に盗まれたら、多くのパスワードをすばやく「リバース」できる。
明確にするために、定数ハッシュでMD5を使用することはひどいパスワードセキュリティです。これを安全にするためにサーバー側で追加の手順が実行されている可能性は常にありますが、MD5は長い間パスワードの使用が推奨されておらず、本当に疑わしいものです。一般に、パスワード認証を使用していて、実際にMD5を使用することについて考えさえしている人は、何をしているのかまったくわかりません。そのため、サーバー側のセキュリティがますます向上している可能性はありますが、パスワードのセキュリティは実際には見た目ほどひどいものだと思います。したがって、システムに「違反」したことは決してありませんが、セキュリティチームでこれを上げることは、そのようなことを安全に（自分にとって）行う方法に精通していて、これが悪い考えである理由を首尾一貫して説明できる場合、合理的なアプローチとなるでしょう。 。
クライアントとサーバー間の通信チャネルが安全であることを推測する（適切に構成されたTLSトンネルのように）マングルされたパスワードまたはプレーンテキストのパスワードを送信しても、直接的な利点や損失はありません認証メカニズムへ。どちらもリプレイ攻撃の影響を受けやすく、パスワードを再生する場合もあれば、変換されたパスワードを再生する場合もあります。 これ自体は脆弱性ではありません。
Ifただし、接続は保護されていません（つまりプレーンテキスト）その後、固定ソルトとmd5ハッシュでパスワードを改ざんすることは、機密データを保護する方法としては不十分です、リプレイ攻撃の影響も同様に受けやすい。 これは脆弱性です。