パスワードをソルトする：ベストプラクティス？

私はいつも好奇心旺盛でした...ハッシュのためにパスワードをソルトするときにどちらが良いですか：プレフィックス、またはポストフィックス？どうして？それとも、塩漬けであれば問題ありませんか？

説明するには：データベースに保存するためにパスワードをハッシュする前に、パスワードをソルトする必要があることを（願わくば）わかっているはずです[ 編集：最近Jeff Atwoodで起こったことなどを避けることができます]。通常、これはソルトをパスワードと連結してから、ハッシュアルゴリズムに渡すことによって行われます。しかし、例は異なります...一部の例は、パスワードの前にソルトを付加します。一部の例では、パスワードの後にソルトを追加しています。塩を真ん中に入れようとする人も見ました。

それで、どちらがより良い方法で、なぜですか？ハッシュの衝突の可能性を減らす方法はありますか？私のグーグルは、そのテーマに関してまともな分析をしていません。

編集：すばらしい回答者の皆さん！一つだけ答えてすみませんでした。:)

接頭辞または接尾辞は関係ありません。それは、パスワードにエントロピーと長さを追加することについてのみです。

次の3つのことを考慮する必要があります。

1. ソルトは、保存するパスワードごとに異なる必要があります。（これはよくある誤解です。）
2. 暗号で保護された乱数ジェネレータを使用します。
3. 十分に長い塩を選択してください。誕生日の問題について考えてください。

ユーザー名（または他の個人データ）の代わりにランダムに生成されたソルトを使用する必要がある別の質問に対するDave Sherohmanによる優れた回答があります。これらの提案に従えば、どこに塩を入れてもかまいません。

それはすべて意味論だと思います。非常に具体的な脅威モデルを除いて、それを前後に配置することは重要ではありません。

そこにあるという事実は、レインボーテーブルを倒すことになっています。

私が言及した脅威モデルは、攻撃者がパスワードに追加/追加された一般的な塩のレインボーテーブルを持つことができるシナリオです。（NSAを言ってください）あなたは彼らがそれを付け加えたか、付け加えたかのどちらかであると推測していますが、両方ではありません。それはばかげている、そしてそれは悪い推測です。

これらには、これらのレインボーテーブルを格納する能力があると想定した方がよいでしょう。その中で狭い場合、私が散在することは最高のだろうと推測します。

私が言ったように。それは意味論です。パスワードごとに異なるソルト、長いソルトを選択し、記号やASCIIコードなどの奇数文字をその中に含めます：©¤¡

本当の答えは誰も触れていないようですが、どちらも間違っているということです。あなたがあなた自身の暗号化を実装している場合は、どんなに些細なA部分あなたは、あなたがやっていると思うんうとしているミスを作ること。

HMACの方が優れていますが、SHA-1などを使用している場合でも、速度の設計上、パスワードハッシュに適さないアルゴリズムをすでに選択しています。bcryptまたはおそらくscryptのようなものを使用して、問題を完全に解決します。

ああ、結果のハッシュがプログラミング言語やデータベース文字列比較ユーティリティと等しいかどうか比較することさえ考えないでください。それらfalseは文字ごとに比較し、文字が異なるかのように短絡します。したがって、攻撃者は統計的手法を使用して、一度に1文字ずつ、ハッシュとは何かを試すことができます。

違いはありません。塩をどこに置いても、ハッシュは簡単に推測できなくなります。ハッシュの衝突は、意図的に非線形であるため、まれであり、予測不可能です。それがセキュリティに変化をもたらした場合、それはソルティングではなくハッシュの問題を示唆します。

暗号化された安全なハッシュを使用する場合、プレフィックスの前置か後置かは問題ではありません。ハッシュのポイントは、ソースデータの単一ビットの変更（場所に関係なく）が異なるハッシュを生成することです。

何で重要な、しかし、適切な暗号PRNGとそれらを生成し、長い塩を使用し、ユーザごとの塩を持っています。ユーザーごとのソルトをデータベースに格納することはセキュリティ上の問題ではありません。サイト全体のハッシュを使用するのはです。

まず、「レインボーテーブル」という用語は一貫して誤用されています。「レインボー」テーブルは特別な種類ですのルックアップテーブルであり、キーで特定の種類のデータ圧縮を可能にします。計算をスペースと交換することにより、1000 TBを必要とするルックアップテーブルを1000回圧縮して、より小さなドライブドライブに格納できます。

パスワードルックアップテーブルへのハッシュ、レインボーなどについて心配する必要があります。

@ onebyone.livejournal.com：

攻撃者は、辞書の単語のハッシュではなく、ハッシュ計算を完了する直前のハッシュ計算の状態で構成される「レインボーテーブル」を持っています。

次に、接頭辞saltよりも接尾辞saltを使用してパスワードファイルエントリを総当たりにする方が安価な場合があります。辞書の単語ごとに、状態を読み込み、ソルトバイトをハッシュに追加して、それを確定します。接頭辞付きのソルトを使用すると、各辞書の単語の計算に共通点はありません。

単純な線形合同ジェネレータなど、入力文字列を線形スキャンする単純なハッシュ関数の場合、これは実用的な攻撃です。ただし、暗号化された安全なハッシュ関数は意図的に複数のラウンドを持つように設計されています。各ラウンドは入力文字列のすべてのビットを使用するため、ソルトを追加する直前の内部状態の計算は、最初のラウンド後は意味がありません。たとえば、SHA-1には80ラウンドあります。

さらに、PBKDFのようなパスワードハッシュアルゴリズムはハッシュ関数を複数回構成します（PBKDF-2を最低1000回反復し、各反復でSHA-1を2回適用することをお勧めします）。この攻撃は二重に非現実的です。

プラットフォームにプロバイダーがある場合、BCryptハッシュ。塩の作成について心配する必要がなく、必要に応じて塩をさらに強くする方法が大好きです。

パスワードに任意の文字数のソルトを挿入することは、最も予想されないケースであり、したがって社会的には最も「安全」ですが、パスワードごとに長くユニークなものを使用している限り、一般的なケースではそれほど重要ではありません。塩の文字列。