パスワード、塩、ハッシュ、DB：百万回のため

Question

私はこのトピックが100万回議論されていることを知っています。しかし、それは私には新しく、実際に何が起こっているのか起こっているのか分かりません。

ユーザーのパスワードのハッシュされた記憶域にユーザーの塩を追加するので、保存されたパスワードハッシュは次のようになります：hash（password + perusersalt）。 これにより、異なるユーザーの同じパスワードが異なる文字列としてDBに格納されます。クール。しかし、誰かがDBに侵入し、ハッシュされたパスワードを調べることに心配していません。私は、ユーザー名とパスワードの組み合わせについて私のサーバーに問い合わせるブルートフォースを心配しています。この場合、ユーザー名とパスワードを正しく組み合わせるとログインが成功するため、塩漬けされハッシュされたパスワードの記憶域は無駄になります。右？

私はこのシナリオで塩がかなり役に立たないという印象の下で正しいですか？サーバーはインターフェイス上のユーザー名とパスワードのみを受け入れるので（塩分は送信されません）、通常の辞書攻撃が有効です。

したがって、塩は、DBにアクセスできるユーザーからのパスワード（逆虹彩テーブルの参照のみで入手可能）を難読化するためにのみ存在します。うーん。

関連：私のWebアプリケーションではプレーンなパスワードも送信されません。パスワードはすでにクライアント側でハッシュされており、盗まれたパスワードに関する責任を完全に拒否するだけで、すべてがSSLを使用します。

ユーザ名とパスワードを正しく組み合わせると、ログインに成功する必要があるため、できるだけ高いセキュリティレベルが得られますか？

私の頭の中の混乱をクリアしていただきありがとうございます。

Answer 1

あなたはブルートフォースアタックについてのあなたの仮定で正しいです。ユーザーが単純なパスワードを持っている場合、塩とハッシュは本当に重要ではありません。辞書攻撃は "パスワード"を推測し、攻撃者を許可します。ユーザーから安全なパスワードを要求し、一方向暗号化（塩でハッシュ）し、あなたのようにSSLを使用する必要があります。

Answer 2

"パスワードはハッシュされたクライアント側[...]から[...]には誰かの盗難されたパスワードについての責任を拒否し、すべてがSSLを使用します。

クライアントはハッシュ（パスワード+塩）を送信しますか？

この設計では、クライアントは正常にログインするためにパスワードを必要とせず、ハッシュだけが必要です。したがって、の実際のパスワード（ハッシュ）が漏洩する責任は引き続き発生する可能性があります。