パスワードを保存するとき、ソルトは秘密にする必要はなく、すべてのハッシュを一意に保つことが唯一の目的であると言われています。パスワードの長さを制限することは良い習慣ではないとも言われていますが、次の例を検討してください。
ハッシュ化する前に、ユーザー入力を最大 100 にトリミングし、ソルトとして追加の文字を追加することにより、プレーン テキスト バージョンが内部的に常に 128 文字であることを確認します。
したがって、ユーザーが 20 文字を入力すると、108 文字のランダムな文字がソルトとして追加されます。ユーザーが 100 を入力すると、28 が追加されます。ポイントは、プレーン テキスト バージョンの長さは 128 文字にする必要があるということです。コードでは、次のようになります。
$salt = generate_salt($pass); // length varies as explained above
$hash = hash('sha512', $pass.$salt);
このようにして、ハッシュ前の「プレーン テキスト」は常に 128 文字になります。
$hash をサーバー A に保存し、$salt をサーバー B に保存します。
ここで、攻撃者がハッシュ DB (サーバー A) へのアクセスを取得し、ハッシュを元に戻すことに成功したと仮定しましょう。彼には良さそうに見えますが、128 文字であるため、彼が見る平文バージョン (または逆ハッシュ) はまだハッシュのように見えます。彼はソルトを知らないので、元のパスワードを決して知りません。
追加の課題として、SHA512 が 128 文字を生成するという事実により、(既に述べたように) プレーン テキスト バージョンはハッシュのように見えるため、プレーン テキスト バージョンに到達したかどうかも確信が持てません。一見すると、彼はそれが反復バージョンであると考えるかもしれません。そうであれば、彼はおそらく無期限に反復を続けるでしょう。
ハッシュの反転が発生した場合、ソルトの秘密を保持するとセキュリティが強化され、プレーンテキストの長さを均一に保つと難読化のレイヤーが追加されるため、このアプローチに問題はありますか?
注: これはもちろん、アプリに複数のログイン失敗の検出/防止機能があることを前提としています。