私はいつも興味があります...ハッシュ用のパスワードをソルトするときは、プレフィックスとポストフィックスのどちらが良いですか？なんで？それとも、あなたが塩を飲む限り、それは重要ですか？
説明：データベースに保存するためにパスワードをハッシュする前に、パスワードをソルトする必要があることを（願わくば）今では知っています[編集：最近JeffAtwoodに起こったことのようなことを避けることができます]。通常、これは、ハッシュアルゴリズムを通過する前に、ソルトをパスワードと連結することによって行われます。しかし、例はさまざまです...いくつかの例では、パスワードの前にソルトを追加します。いくつかの例では、パスワードの後にソルトを追加します。塩を真ん中に入れようとする人もいます。
では、どちらがより良い方法であり、なぜですか？ハッシュ衝突の可能性を減らす方法はありますか？私のグーグルは、この主題についてまともな分析をしていません。
編集：素晴らしい答えの人々！申し訳ありませんが、答えは1つしか選べませんでした。:)
プレフィックスまたはサフィックスは関係ありません。パスワードにエントロピーと長さを追加するだけです。
次の 3 つのことを考慮する必要があります。
ユーザー名 (またはその他の個人データ) の代わりにランダムに生成されたソルトを使用する必要がある理由について、別の質問に対するDave Sherohman による優れた回答があります。これらの提案に従えば、どこに塩を入れるかは問題ではありません。
それはすべてセマンティクスだと思います。非常に特殊な脅威モデルに対する場合を除いて、前後に置くことは重要ではありません。
そこにあるという事実は、レインボー テーブルを打ち負かすことになっています。
私がほのめかした脅威モデルは、攻撃者が一般的なソルトのレインボー テーブルをパスワードに追加/先頭に追加できるシナリオです。(NSA と言ってください) あなたは、彼らがそれを追加するか先頭に追加するかのどちらかを持っていると推測していますが、両方を持っているわけではありません。それはばかげています、そしてそれは悪い推測です。
これらのテーブルには、これらのレインボー テーブルを格納する容量があると想定したほうがよいでしょう。その狭いケースでは、散在するのが最適だと思います。
私が言ったように。それはセマンティクスです。パスワードごとに異なるソルト、長いソルトを選択し、記号や ASCII コードなどの奇妙な文字を含めます: ©¤¡
誰も触れていないように見える本当の答えは、どちらも間違っているということです。独自の暗号化を実装している場合、実行していると思っている部分がどれほど些細なことであっても、間違いを犯すことになります。
HMACの方が優れたアプローチですが、それでも SHA-1 などを使用している場合は、速度を重視した設計のため、パスワード ハッシュには不適切なアルゴリズムを既に選択しています。bcryptや場合によってはscryptなどを使用して、問題を完全に解決してください。
ああ、結果のハッシュをプログラミング言語やデータベースの文字列比較ユーティリティと比較して等しいかどうかについても考えないでください。falseそれらは文字ごとに比較され、文字が異なるかのように短絡します。そのため、攻撃者は統計的手法を使用して、一度に 1 文字ずつ、ハッシュが何であるかを調べようとすることができます。
違いはありません。どこに塩を置いても、ハッシュは簡単に推測できなくなります。ハッシュの衝突は、意図的に非線形であるため、めったに発生せず、予測不可能です。セキュリティに違いが生じた場合、それはソルティングではなくハッシュに問題があることを示唆しています。
暗号的に安全なハッシュを使用する場合は、前置または後置のどちらでも構いません。ハッシュのポイントは、ソースデータの1ビットの変更（どこに関係なく）が異なるハッシュを生成する必要があるということです。
ただし、重要なのは、長いソルトを使用し、適切な暗号化PRNGを使用してそれらを生成し、ユーザーごとのソルトを使用することです。ユーザーごとのソルトをデータベースに保存することはセキュリティの問題ではなく、サイト全体のハッシュを使用することはセキュリティの問題です。
プラットフォームにプロバイダーがある場合はBCrypt ハッシュ。ソルトを作成することを心配せずに、必要に応じてソルトをさらに強化できることが気に入っています。
パスワードに任意の文字数のソルトを挿入することは、最も期待されていないケースであり、したがって社会的に最も「安全」ですが、パスワードごとに長い一意のパスワードを使用している限り、一般的なケースではそれほど重要ではありません塩の弦。