パスワードのハッシュとソルトを処理するさまざまな方法について少し調査またはグーグルで調べていたところ、次の興味深いリンクに出くわしました。
さて、これが本質的に提案するのは、ハッシュ用とハッシュチェック用の2つのユーザー関数の作成です。
ソルトは疑似ランダムですが、実際にはパスワードに基づいています（私を悪いと思いますか？）。
ハッシュ関数はまた、ハッシュ文字列の中にソルトを疑似ランダムに「振りかけ」ます。
ハッシュチェック機能は、塩の振りかけを元に戻し、実際のハッシュチェックが行われます。
これで、パスワードハッシュごとに一意のソルト=良いだけでなく、パスワードをハッシュしてdb関数に格納されたソルトを作成するロジックがある=悪いかもしれないことも知っています。
ソルトが明確ではなく、ユーザー名、ユーザーID、生年月日などの一貫した値に基づく必要がないという考えは気に入っていますが、前述したように、実装については疑問があります。
では、「ベストアプローチソリューション」に対する人々の意見やアイデアは何でしょうか。
塩は秘密にする必要はありません。特定のパスワードに対して予測不可能である必要があります。
パスワードからソルトを導出することは、要点を完全に見逃しています。
ソルトの目的は、レインボー テーブルの使用を法外に高価にすることなので、試行 1 で問題はほぼ正しく解決されます。パスワードに基づいてソルトを設定すると、レインボー テーブルを打ち負かす変動性がなくなります。ハッシュ化されたパスワード フィールドにソルトを隠そうとするのは無意味です。
以前、同様の質問をしました。コンセンサスは次のとおりでした。
次の条件を満たしている限り、どのように塩漬けするかは問題ではありません。
ハッシュ化されたパスワードのすぐ隣にソルトを保存することもでき、かなり自信を持って感じることができます.
個人的には、Salt には GUID (文字列形式) がうまく機能することがわかりました。それらは生成するのに1行のコードを必要とし、文字列形式では、レインボーテーブルを計算するのに数千年かかるのに十分な大きさです.
（最初に記事を読み違えて、塩と無塩のハッシュを混ぜただけだと思ったので、回答を編集しました）
彼の技術はうまくいくように見えますが、実際には通常の塩漬け方法よりも「優れている」わけではありません. これは、あいまいにすることでセキュリティを確保しようとする試みにすぎません。独自のランダムな「ハッシュ スクランブリング」方式を作成し、攻撃者がそれを理解しないことを期待することに勝るものはありません。
実際、多くの場合、攻撃者がこれらの機能を理解するのは非常に簡単です。サイトが公開登録されている場合、攻撃者は既知のパスワードでアカウントを繰り返し登録し、それらのパスワードに既知の md5 ハッシュを使用して、パスワード スクランブリング アルゴリズムをリバース エンジニアリングする可能性があります。彼の「試行 4」の結果を見ても、これは非常に簡単に実行できます。
パスワードを本当に安全に保存したい場合は、MD5 や SHA1 から離れて、ソルト化された低速のハッシュ関数に移行してください。これはトピックに関する素晴らしい記事です: レインボー テーブルで十分: 安全なパスワード スキームについて知っておくべきこと
以前にも同様の質問がたくさんありました：
これで、パスワードをハッシュする方法がわかります。
これは、(チャド・バーチが誤解していると指摘したように) 塩漬けハッシュ法に、セキュリティではなく難読化を追加するだけのようです。
興味深いことに、これは単なる難読化ではなく、セキュリティの強化ではなく、実際には難読化であり、セキュリティが低下します。これは、「Attempt 4」は、使用するCRC32関数と同じくらい優れているためです（CRC32には、パスワード+塩ではなく、パスワードのみが渡されます）。没落。
Chadの投稿によると、「Attempt 4」をクラックするには、CRC32でパスワードをロードし、コード化した関数を逆にして、ソルトされたmd5ハッシュとソルト（有効性をテストします）を残します。 。md5（password + salt）（passwordは試行しているパスワード）を計算してこのペアをテストするだけで、saltはアルゴリズムを逆にして計算したsaltです。md5がハッシュの最初の32文字に等しい場合は、パスワードを解読したことになります。
「Attempt4」は、「Attempt 1」よりも悪いです。これは、ルーチン全体で呼び出される最悪の関数、この場合はCRC32（password）と同じくらい良いためです。
元の質問のリンクを表示できません (ウェブサイトは 404 not found エラーを返すだけです) が、質問で説明されている方法は実際にはソルト ハッシュを使用していません。
本質的に、このメソッドは非標準のハッシュを使用しているだけです。特定のパスワードを指定すると、データベースに格納される一意の値が 1 つあります。レインボー テーブル攻撃を機能させるために必要なことはこれだけです。可能性の高いパスワードの辞書のハッシュ値を事前に計算し、一致するものを探すことができます。ここで、この非標準ハッシュ関数専用のレインボー テーブルを事前計算する必要があります。
ソルトハッシュの適切な実装では、パスワードが作成されると、ランダムなソルトがパスワードと組み合わされてハッシュされます。次に、使用されるランダムソルトとハッシュが保存されます。パスワードを知っていても、考えられる多くのソルト値ごとに異なるハッシュが存在するため、ハッシュがどうなるかを予測できません。攻撃者は、可能なソルト値ごとにレインボー テーブルを事前計算する必要があります。これには、はるかに大きな労力がかかります。