ランダムソルトによるハッシュされたパスワードストレージ
ユーザーがユーザー名とパスワードでログインする必要のあるサイトを作成して以来、ソルトフレーズでハッシュされたデータベースにパスワードを保存することで、常にパスワードをいくらか安全に保っています。さて、最近読んだところ、単一の静的ソルトワードを使用するのは悪い習慣です。代わりに、ユーザーごとにランダムなソルトを使用する必要があります。
私は、ユーザーごとにランダムなソルトワードを生成することを理解しています。しかし、私の質問は、ランダムなソルトをデータベースにも保存して、後でそれを相互参照して、ユーザーが入力したパスワードをログイン時にチェックできるようにする必要がある場合です。ユーザー名とパスワードがデータベースから盗まれたら、ランダムなソルト値にも同じようにアクセスできませんか？セキュリティの追加レイヤーは、方程式に多くを追加するものではないようです。
それとも私はこれについてすべて間違っていますか？
重要なことが1つ追加されます。データベースを盗む場合、ユーザー名、ユーザーごとのランダムなソルト、ハッシュされたパスワードを持っています。ただし、元のパスワードはまだありません。ハッシュを元に戻すには、通常、ユーザーごとにかなりの量の個別の作業を行う必要があります。
anysalt（LinkedInが学習したように非常に悪い考え）がない場合、攻撃者は既存の Rainbowテーブル を使用でき、テーブルから恩恵を受けるハッシュのユーザーごとの作業。ハッシュの一部がテーブルにない場合でも、それらは作業をプールすることができます（たとえば、ユーザーが同じあいまいなパスワードを持つ2つのアカウントを持っている場合）。
サイトごとのソルトを使用すると、サイトのRainbowテーブルを生成し、ユーザー間で作業を共有できます。
ユーザーのパスワードを解読した場合、サイトにログインできるだけでなく、ユーザーが使用している他のサイトにもログインできる可能性があることに注意してください。
サイト全体でパスワードを解読するために、レインボーテーブルではなく、ユーザーごとにレインボーテーブルを生成するように強制します。また、ハッシュ値をグーグルでググできないということも意味します。これが「究極のレインボーテーブル」です。それはクラッキングの命題をはるかに難しいタスクに変えます。
Google「5f4dcc3b5aa765d61d8327deb882cf99」。何が表示されるかを確認します（ヒントはパスワードのMD5ハッシュであり、何千もの結果があります）。
異なる塩ですべてのパスフレーズをハッシュすることは、1つの塩を使用するよりも優れていますが、1つの塩は塩をまったく使用しないよりも優れています。
Saltは、ユーザーごとに異なるパスワード処理を行うためのものです。そうでない場合、データベースのコピーを取得した攻撃者（この状況を想定しているため、パスワードがハッシュされます）は、検索を最適化してすべてのパスワードを攻撃できます。単一のパスワードを破るのと同じ努力で（他の事前計算されたテーブルと同様に、Rainbowテーブルはこの概念の化身です）。ユーザーごとのソルトを使用すると、少なくとも、攻撃者は解読しようとする各パスワードに対して全力を尽くします。
（理想的には、ユーザーごとのソルトを使用します。これは、ユーザーがパスワードを変更するたびに変更されます。したがって、実際にはパスワードごとのソルトです。）
塩は話の半分にすぎません。また、ハッシュメカニズムをslowにしたいとします（構成可能な方法ですが、それでも非常に遅くなります）。単純なハッシュは速すぎ、攻撃者は文字通り毎秒数十億ものハッシュを計算できます。
bcryptを使用 。 bcryptの実装はソルトの生成と使用を処理し、bcryptは必要なだけ遅くすることができます。
パスワードを個別にソルトすることで、時間とメモリのトレードオフ（レインボーテーブル）などのオフラインの事前計算ステップを利用した攻撃を防ぐことができます。これにより、攻撃者はハッシュをブルートフォースにしてパスワードを回復します。この ブログ投稿 は、安全性が最も低いものから最も安全なものまで、いくつかのパスワードストレージ戦略の詳細を示しています。
MD5やSHA-1でハッシュしたくないと付け加えておきます。これらは高速ハッシュになるように設計されています。これは、誰かがあなたのパスワードリストを解読しようとしているときにあなたが望むものとは正反対です。低速になるように設計されたbcryptによるハッシュ。これは、多くの開発者が見落としているオプションです。