ソルトとハッシュ、ユーザー名を使用してみませんか？
Webアプリケーションに関連するハイテクセキュリティの問題のほとんどについてほとんど無知であることを告白しなければなりませんが、それは（願わくば）具体的な答えを伴う直接的な質問であるため、少なくとも私が尋ねることができると思ったことが1つあります。
このウェブサイトをご覧ください： http://www.15seconds.com/issue/000217.htm
それらがソルト値をテーブルに格納していることを少し下に示しています。私はその背後にある原理と数学を理解していますsingソルトですが、これは疑問に思っています。
- なぜ彼らはユーザー名を生成する代わりにソルト値として使用しなかったのですか？
ユーザー名はランダムソルトよりもエントロピーが低いため、適切なソルトよりもハッシュが分散されません。
とにかく、そのページの例が非常に壮観であるというわけではありません。私はいつもGUIDを生成し、それを使用します。
実際のセキュリティに関する限り、それはすべて騒がしいと思います。ユーザーごとのソルトが非常に少量であっても、セキュリティに大きな違いがあり、ソルトが複雑になるにつれて改善はごくわずかです。
塩のポイントはユニークであることです。ソルトは、攻撃コストの共有を防ぐことを目的としています。つまり、攻撃者が2つのハッシュされたパスワードを1つを攻撃するコストの2倍未満で攻撃しようとします。
一意性を確保するための1つの解決策は、十分に広いスペースでランダムなソルトを生成することです。したがって、2つの異なるパスワードインスタンスに対して2倍の同じソルトを取得することは、実際には発生しない可能性が十分にあります。
ユーザー名はnot十分に一意です：
- ユーザーがパスワードを変更しても、ユーザー名は変更されません。古いハッシュパスワードと新しいハッシュパスワードを見た攻撃者は、どちらか一方を攻撃するコストの2倍未満のコストで両方を攻撃する可能性があります。
- ある時点で、ユーザー名はシステム全体で一意であり、世界中で一意ではありません。そこには多くの「ボブ」があります（Unixシステムでは「ルート」を検討してください）。ユーザー名を使用すると、攻撃者が複数のシステムを同時に攻撃する可能性があります。
塩のエントロピーは、ランダムな生成設定で一意性を保証する場合を除いて、それほど重要ではありません。
どうですか：
Salt = CryptoHash( CryptoHash(SubmittedEmailOrUsername) . CryptoHash(SubmittedPasswd) ) ?
それは一見
- 動的に計算できるため、塩を保管する必要がないという利点があります。
良好なエントロピー（平文ではなくハッシュベース）を維持しながら、
128-512ビットなどの暗号化ハッシュと同じ長さのソルトを提供しますか？
1つの問題は、システムが2人のユーザーにユーザー名とパスワードの使用を許可した場合です（ただし、電子メールアドレスでは発生しません）が、このスキームに他の問題はありますか？