適切なパスワードハッシュに関係するすべてのことについて、豊富なブログ投稿、チュートリアル、および SO の質問を読みました。しかし、クライアント側のハッシュのリスクについて、まだ 1 つの疑問があります。
JavaScript のクライアント側でユーザーのパスワードをソルト & ハッシュしたい場合、再ハッシュ & ソルトはサーバー上で行われ、すべてのデータは HTTPS (プレーン テキストなし) 経由で送信されます。クライアント側のハッシュは、サーバーと同じソルトまたはアルゴリズムを使用しません。
サーバーにとって論理的には、ユーザーのパスワードはハッシュであるため、データ送信がプレーンテキストであった場合、パスワードがハッシュされているかどうかは問題ではありません。JavaScript が読み取られ、クライアント側のハッシュが公開された場合、既知の長さと文字 (0-9 & af) のハッシュを取得する方が理論的に簡単ですか?可変長のパスワードとすべての英数字、大文字と小文字を取得することです &小文字と特殊文字？
たとえば、クライアント側での基本的な MD5 ハッシュ (MD5 が悪いことはわかっています) は、128 ビット (16 バイト) のハッシュを生成します。したがって、16 の可能な文字で、16^16 = 1.84e19 の可能なハッシュになります。
長さ 8 ～ 10 文字のパスワードで、任意の英数字または特殊文字から選択します (ウィキペディアのカウントによると、それは 95 です)。95^8 + 95^9 + 95^10 となり、6.05e19 となります。ご覧のとおり、これはハッシュよりもパスワードの量の 3 倍以上です (そして、この数は、パスワードを必要なだけ長くすることを許可するだけで、より大きくなります)。
ハッシュ化されたパスワードをクライアントからサーバーに送信しないほうがよいのではないでしょうか?
この質問の2番目の部分として、読書から、辞書などのツールを使用して、この可能性の数を論理的に減らすことができることを理解しています. これらのツールは、ハッシュの 1.84e19 の組み合わせの下に結果を本当に絞り込むことができますか?