1

このアプローチを使用している人々について聞いたことがありますが、その影響を知りたいと思っています。私はそれが悪い考えであることを知っています！

私が理解していることから、ハッシュをDBに保存する前にパスワードをソルトすることには、すべてのハッシュアルゴリズムを一意にするという主な目的があるため、クラックしようとするとすべてのユーザーに新しいレインボーテーブルが必要になります。

プレーンテキストがそれ自体でソルトされただけの場合、このコンテキストでハッシュはどのように弱められますか?

例：

plainText = input();
saltedText = plainText + plainText;
hashedText = hash(saltedText);
db.store(hashedText);

そして、次のアプローチには同じ弱点がありますか、それとも他の弱点がありますか?

plainText = input();
saltedText = hash(plainText) + plainText;
hashedText = hash(saltedText);
db.store(hashedText);
4

3 に答える 3

2

あなたは塩の目的を誤解していると思います。ソルトとは、同じデータを2回ハッシュすると、（通常は）2つの異なる結果が得られることを意味します。これにより、特定のハッシュを作成できる値を知っていると、同じパスワードを使用するすべての人にログインできる攻撃を防ぐことができます。

そのため、ハッシュされるテストを複製しても、より多くのデータをハッシュするというパフォーマンスヒット以外の利点はありません。

于 2010-10-27T11:54:53.147 に答える
1

どちらの方法でもソルトは予測可能であるため、必要なレインボー テーブルは 1 つだけです。

文字列をハッシュするたびに、異なるソルトを使用する必要があります。

plainText = input();
salt = getRandomSalt();
hashedText = hash(salt + plainText);
db.store(salt, hashedText);
于 2010-10-27T12:16:06.207 に答える
0

他の人があなたの実装の問題を説明しています。

(ソルトを保存する必要を避けるために) ソルトを派生させたい場合は、別のユーザー固有のソルト ソースが必要です。

たとえば、アカウント ID、ユーザー名、または電子メール アドレスをソルト ソースとして使用できます。明らかに、ソルトとして直接ソースを使用するべきではなく、代わりに PBKDF2 のようなキー派生関数を使用する必要があります。

基礎となるソルトソースが変更された場合、パスワードを再ハッシュする必要があることに注意してください。これは、キー情報を変更する前にユーザーにパスワードを要求することで実装できます (ユーザーを検証し、提供されたパスワードを使用してソルト ソースで再ハッシュします)。

于 2010-11-15T14:55:09.823 に答える