encryption - ソルトとハッシュ、ユーザー名を使用してみませんか？

Question

Webアプリケーションに関連するハイテクセキュリティの問題のほとんどについてほとんど無知であることを告白しなければなりませんが、それは（願わくば）具体的な答えを伴う直接的な質問であるため、少なくとも私が尋ねることができると思ったことが1つあります。

このウェブサイトをご覧ください：http ：//www.15seconds.com/issue/000217.htm

それは彼らが塩の値を表に保存していることを少し下に示しています、私は塩を使用することの背後にある原理と数学を理解しています、しかし私はこれを疑問に思っています：

なぜ彼らはユーザー名を生成する代わりにソルト値として使用しなかったのですか？

score 43 · Accepted Answer

塩のポイントはユニークであることです。ソルトは、攻撃コストの共有、つまり、攻撃者が1つを攻撃するコストの2倍未満で2つのハッシュされたパスワードを攻撃しようとするのを防ぐことを目的としています。

一意性を確保するための1つの解決策は、十分に広いスペースでランダムなソルトを生成することです。したがって、2つの異なるパスワードインスタンスに対して2倍の同じソルトを取得することは、実際には発生しない可能性が十分にあります。

ユーザー名は十分に一意ではありません：

ユーザーがパスワードを変更しても、ユーザー名は変更されません。古いハッシュ化されたパスワードと新しいハッシュ化されたパスワードを見た攻撃者は、どちらか一方を攻撃するコストの2倍未満のコストで両方を攻撃する可能性があります。
ある時点で、ユーザー名はシステム全体で一意であり、世界中で一意ではありません。そこには多くの「ボブ」があります（Unixシステムでは「ルート」を検討してください）。ユーザー名を使用すると、攻撃者が複数のシステムを同時に攻撃する可能性があります。

塩のエントロピーは、ランダムな生成設定で一意性を保証する場合を除いて、それほど重要ではありません。

score 30 · Accepted Answer

ユーザー名はランダムソルトよりもエントロピーが低いため、適切なソルトよりもハッシュが分散されません。

そのページの例はとにかく非常に壮観であるというわけではありません。私は常にGUIDを生成し、それを使用します。

実際のセキュリティに関する限り、それはすべて騒がしいと思います。ユーザーごとのソルトが非常に少量であっても、セキュリティに大きな違いがあり、ソルトが複雑になるにつれて改善はごくわずかです。

score 1 · Accepted Answer

どうですか：

Salt = CryptoHash( CryptoHash(SubmittedEmailOrUsername) . CryptoHash(SubmittedPasswd) ) ?

それは一見

1つの問題は、システムが2人のユーザーにユーザー名とパスワードの使用を許可した場合です（ただし、email addrでは発生しません）が、このスキームに他の問題はありますか？

3 に答える 3