encryption - ユーザーパスワードソルトの最適な長さはどれくらいですか？

Question

ユーザーのパスワードをソルトおよびハッシュする場合は、ソルトがあれば明らかに役立ちます。塩の長さに関するベストプラクティスはありますか？ソルトをユーザーテーブルに保存するので、ストレージサイズとセキュリティの間の最良のトレードオフが必要です。ランダムな10文字の塩で十分ですか？それとももっと長いものが必要ですか？

Answer 1

これらの回答のほとんどは少し見当違いであり、ソルトと暗号化キーの間の混乱を示しています。ソルトを含める目的は、各ユーザーのパスワードをハッシュするために使用される関数を変更して、保存されている各パスワード ハッシュを個別に攻撃する必要があるようにすることです。唯一のセキュリティ要件は、それらがユーザーごとに一意であることです。それらが予測不能または推測困難であることには何の利点もありません。

ソルトは、各ユーザーのソルトが一意になるように十分な長さだけが必要です。ランダムな 64 ビット ソルトは、10 億人の登録ユーザーがいる場合でも繰り返される可能性は非常に低いため、これで問題ありません。ソルトが 1 回繰り返されることは、比較的小さなセキュリティ上の問題です。攻撃者は一度に 2 つのアカウントを検索できますが、全体としてデータベース全体の検索速度はそれほど速くなりません。32 ビットのソルトでさえ、ほとんどの目的に使用できます。最悪の場合、攻撃者の検索速度が約 58% 速くなります。64 ビットを超えてソルトを増やすコストは高くありませんが、そうするセキュリティ上の理由はありません。

ユーザーごとのソルトの上にサイト全体のソルトを使用することにもいくつかの利点があります。これにより、他のサイトに保存されているパスワードハッシュとの衝突の可能性が防止され、汎用レインボーテーブルの使用が防止されます。塩はレインボーテーブルを非現実的な攻撃にするのに十分です.

さらに単純なことに、開発者は常にこれを見落としていますが、一意のユーザー ID またはログイン名を持っている場合、それらは完全にソルトとして機能します。これを行う場合は、サイト全体のソルトを追加して、同じ優れたアイデアを持つ別のシステムのユーザーと重複しないようにする必要があります。

Answer 2

パスワードをハッシュするために現在受け入れられている標準は、すべてのパスワードに対して新しい16文字の長さのソルトを作成し、パスワードハッシュとともにソルトを格納します。

もちろん、本当にランダムなソルトを作成するための適切な暗号化の注意を払う必要があります。

Answer 3

編集:私の以下の回答は、尋ねられたとおりに質問に回答しますが、「本当の」回答は、単にbcrypt、scrypt、またはArgon2を使用することです。このような質問をしている場合は、ツールの使用レベルが低すぎることはほぼ間違いありません。

正直なところ、salt をハッシュ化されたパスワードとまったく同じ長さにしない正当な理由はありません。SHA-256 を使用している場合は、256 ビットのハッシュがあります。256 ビットのソルトを使用しない理由はありません。

数学的には、256 ビットを超えてもセキュリティが向上することはありません。しかし、より短いソルトを使用すると、レインボーテーブルがソルトの長さに追いつく状況になる可能性があります。特に、より短いソルトでは.

Answer 4

ウィキペディア:

Linux、BSD Unix、および Solaris で使用される SHA2-crypt および bcrypt メソッドには、128 ビットのソルトがあります。これらのより大きなソルト値により、近い将来、これらのシステムに対して、ほぼすべての長さのパスワードに対する事前計算攻撃が実行不可能になります。

128 ビット (16 バイト) のソルトで十分です。128 / 4 = 32一連の16 進数で表すことができます。