パスワードを塩漬けする：ベストプラクティス？
私はいつも興味があります...ハッシュするためにパスワードをソルトするとき、どちらが良いですか：プレフィックス、またはポストフィックス？どうして？それとも、塩を注いでいる限り重要ですか？
説明するには：データベースに保存するためにハッシュする前に salt パスワードを使用する必要があることを（願わくば）全員が知っている[Edit：したがって、 最近Jeff Atwoodに起こったこと ]のようなことを避けることができます。通常、これは、ソルトをハッシュアルゴリズムに渡す前にパスワードと連結することによって行われます。ただし、例はさまざまです...パスワードの前にソルトを追加する例もあります。いくつかの例では、パスワードの後にソルトを追加します。塩を真ん中に入れようとする人を見たことがあります。
では、どちらがより良い方法であり、なぜですか？ハッシュ衝突の可能性を減らす方法はありますか？私のグーグルは、このテーマに関するきちんとした分析を行っていません。
編集：すばらしい答えです！申し訳ありませんが、答えを1つしか選択できませんでした。 :)
プレフィックスまたはサフィックスは無関係であり、パスワードにエントロピーと長さを追加するだけです。
これらの3つのことを考慮する必要があります。
- 格納するパスワードごとにソルトが異なる必要があります。 （これは非常によくある誤解です。）
- 暗号的に安全な乱数ジェネレーターを使用します。
- 十分な長さの塩を選択してください。誕生日の問題について考えてください。
ユーザー名（またはその他の個人データ）の代わりにランダムに生成されたソルトを使用する必要がある別の質問に対する優れた Dave Sherohmanによる回答 があります。これらの提案に従えば、塩をどこに入れるかは本当に関係ありません。
すべてのセマンティクスだと思います。非常に特定の脅威モデルに対する場合を除いて、前後に配置することは重要ではありません。
そこにあるという事実は、レインボーテーブルを打ち負かすことになっています。
私がほのめかした脅威モデルは、攻撃者canにパスワードに追加/追加された共通ソルトのRainbowテーブルがあるシナリオです。 （NSAと言ってください）あなたは彼らがそれを追加または追加したのではなく、両方を持っていると推測しています。それはばかげている、そしてそれは貧弱な推測です。
これらのRainbowテーブルを保存する能力があると仮定する方が良いでしょう。しかし、例えば、パスワードの途中に奇妙な塩が点在するテーブルはそうではありません。 thatナローケースでは、散在するのが最適であると推測します。
私が言ったように。セマンティクスです。パスワードごとに異なるソルト、長いソルトを選択し、記号やASCIIコード：©¤¡
誰も触れていないように見える本当の答えは、 両方とも間違っています です。独自の暗号を実装している場合、自分がやろうと思っている部分がどんなに些細なものであっても、間違いを犯すことになります。
[〜＃〜] hmac [〜＃〜] はより良いアプローチですが、SHA-1のようなものを使用している場合でも、パスワードハッシュに適さないアルゴリズムをすでに選択しています。速度のためのその設計のため。 bcrypt またはおそらく scrypt のようなものを使用して、問題を完全に解決してください。
ああ、結果のハッシュをプログラミング言語やデータベース文字列比較ユーティリティと比較することも考えないでください。これらは文字ごとに比較し、文字が異なる場合はfalseとして短絡します。そのため、攻撃者は統計的手法を使用して、一度に1文字ずつ、ハッシュとは何かを試すことができます。
違いはありません。塩はどこに置いてもハッシュは簡単に推測できなくなります。ハッシュ衝突は、意図的に非線形であるため、まれで予測不可能です。セキュリティに違いがあれば、それはソルティングではなくハッシュの問題を示唆しています。
暗号化された安全なハッシュを使用する場合、前置または後置のどちらでもかまいません。ハッシュのポイントは、ソースデータの1ビットの変更（どこでも）が異なるハッシュを生成することです。
何 は ただし、重要なのは、長いソルトを使用し、適切な暗号化PRNGで生成し、ユーザーごとのソルトを使用することです。データベースにユーザーごとのソルトを保存するのは じゃない サイト全体のハッシュを使用したセキュリティ問題 は。
まず第一に、「レインボーテーブル」という用語は一貫して誤用されています。 「レインボー」テーブルは、ルックアップテーブルの特定のkindであり、キーの特定の種類のデータ圧縮を可能にします。計算をスペースと交換することで、1000 TBを必要とするルックアップテーブルを1000回圧縮することができ、より小さなドライブドライブに保存できます。
Rainbowかそれ以外のパスワードルックアップテーブルへのハッシュを心配する必要があります。
@ onebyone.livejournal.com：
攻撃者は、辞書の単語のハッシュではなく、ハッシュ計算を完了する直前のハッシュ計算の状態で構成される「レインボーテーブル」を持っています。
プレフィックスソルトよりも後置ソルトを使用してパスワードファイルエントリをブルートフォースする方が安くなる可能性があります：各辞書ワードに対して、状態をロードし、ソルトバイトをハッシュに追加してからファイナライズします。接頭辞付きソルトでは、各辞書のWordの計算に共通点はありません。
単純な線形合同ジェネレーターなど、入力文字列を線形にスキャンする単純なハッシュ関数の場合、これは実用的な攻撃です。しかし、暗号的に安全なハッシュ関数は、それぞれが入力文字列のすべてのビットを使用する複数のラウンドを持つように意図的に設計されているため、内部状態の計算直前はソルトの追加に意味がありません最初のラウンドの後。たとえば、SHA-1には80ラウンドがあります。
さらに、PBKDFなどのパスワードハッシュアルゴリズムは、ハッシュ関数を複数回構成します（PBKDF-2を最低1000回反復し、各反復でSHA-1を2回適用することをお勧めします）。この攻撃は二重に非実用的です。
BCrypt hash プラットフォームにプロバイダーがある場合。私はあなたが塩を作ることを心配しない方法が好きで、望むなら塩をさらに強くすることができます。
パスワードに任意の文字数のソルトを挿入することは、最も期待されないケースであり、したがって社会的に最も「安全」ですが、パスワードごとに長くユニークなものを使用している限り、一般的なケースではあまり重要ではありません塩の文字列。