これが「過剰に求められている」トピックであることは承知していますが、Bcrypt安全性に関していくつか懸念があります。
私は を使用してsha512($password.$salt)から、より良い解決策を探し、出会いましBcryptた。
私が気になったのは、それについて読んだときに、ラウンド数（$02$）とソルトがハッシュ内に3つの別々の「ブロック」に保存されていると言って$rounds$.$salt.$hashいました（または、少なくともそれが私が解釈した方法です）。
私の質問は次のとおりです。これは安全ではありませんか? 使用したラウンドの数を表示し、塩を明確に利用できます。攻撃者は「OK、2 ラウンドが必要です。ソルトは 123 ソルトで、それがハッシュです」と言うことができるからですよね？
読んでいるとき、安全であることは「すべて」ではなく、パスワードをクラックするのにかかる時間であり、それがBcryptの利点であり、遅いことを理解しています.
誰か私の誤解/誤解を明確にしてもらえますか?
ありがとう。
ソルトのポイントは、攻撃者が複数のユーザーに対して計算を再利用するのを防ぐことです。
攻撃者に渡しても問題ありません。
同様に、攻撃者があなたが使用しているラウンド数を知っていたとしても、それはそれほど長くはありません (かなり多くのラウンド数を使用していると仮定して)。
多くのラウンドを使用するポイントは、攻撃者が使用するラウンド数がわからないということではありません。ラウンドごとに攻撃に時間がかかるようになります。
ハッシュごとに同じソルトを使用していたsha512を使用した以前のアプローチとは異なり、ハッシュごとに異なるソルトが使用されるため、ソルトはハッシュとともに保存されます。
この方法では、単一のレインボーテーブルは単一のパスワードにのみ適していますが、すべてのハッシュに同じソルトが使用されている場合は、単一のレインボーテーブルがすべてのハッシュに適しています。
ハッシュを正しく検証できるように、作業係数（いわゆる「ラウンド」）も保存する必要があります。はい、それを取り除くことはできますが、実際には害はありません。
bcryptは集中的なアルゴリズムになるように設計されています。単一のハッシュを計算するのはコストがかかり、作業係数の高いハッシュのルックアップテーブルを作成することは不可能です。
作業係数は技術の進歩に応じて変更されるように設計されているため、bcryptハッシュをクラックすることは常に困難です。ただし、ハッシュをアップグレードできるのは、パスワードを確認している最中のみです。
アップグレードされたハッシュとアップグレードされていないハッシュに応じて、ハッシュごとに異なる作業負荷値が格納されているシステムになってしまう可能性があります。