パスワード認証/登録システムの設計

Question

私はウェブサイトのユーザー登録/認証システムを設計していて、パスワードベースの認証のためにこの設計を思いついた。

これが妥当かどうか知りたいのですが。（資格情報、oauthなどをキャッシュするためのCookieを無視します）

私がデザインに組み込んだもののいくつかは、セキュリティにどれだけ「役立つ」かわかりません。

サーバーデータベースが危険にさらされた場合、hashedPwがクライアントから送信されるため、saltedSecretを再検証できます。（hashedPwはサーバーに保存されません）
リプレイ攻撃を防ぐためのチャレンジ（chalSecret）
scryptのコストは時間の経過とともに調整可能ですが、ブラウザーでscryptのjavascript実装を使用することを期待しているので、それほど優れた機能ではないかもしれません。

もう1つの質問は、ユーザー登録時にsaltedSecretの最初の送信を簡単に保護できるかどうかですが、HTTPSを使用するだけで十分だと思います。

これを単純化する方法があれば、教えてください。

注：この設計を簡素化する変更については、以下の編集セクションを参照してください。

authentication design

編集：これを投稿してから私に起こったいくつかのこと：

TLSはリプレイ攻撃から保護しますなので、チャレンジセクション全体を削除できます。
サーバー側では、（少なくとも）saltedSecretのハッシュを保存する必要があります。最良の方法は、そのスクリプトを保存することです。これには、ログイン時にhashedPwを送信するというユーザーの要件を削除するという良い副作用があります。
これらの変更を含む新しい図：

thexacre · Answer

私が見ている問題は、ユーザーのパスワードの送信を回避するために多くの努力をしている一方で、saltedSecretが本質的にパスワードになっていることです。

送信されたパスワードに対する主な脅威は、man-in-the-middle（MITM）がパスワードを監視し（他の形式の暗号化がない場合）、システムにログインできることです。

MITMがシステムを悪用する方法を見ると、次のようになります。

彼らは、登録またはログインのいずれかからsaltedSecretを監視します（フロー1または7）
彼らはログイン要求を行い、認証される前にchallengeSaltとchalCostに通知されます。（フロー2）
彼らは知っているsaltedSecretを使用してchalSecretを生成し、ログインします（フロー7）

ただし、saltedSecretを保存し、hashedPwまたはsaltedSecretをフロー7に返送しないことで、これを部分的に軽減できます。最初のsaltedSecretからは引き続き脆弱です。フロー5。

ただし、saltedSecretを格納する場合は、サーバー側でもソルティングとハッシュのスキームが必要になるため、これは依然として問題があります。そうしないと、データベースが何らかの形で侵害された場合、データベースはこれらの値を使用してシステムにログインできます。ただし、saltedSecretをハッシュすることにより、サーバー側でchalSecretを再構築し、生成されたsaltedSecretをクライアント側から送信することを回避できなくなります。

一般に、TLSなどのトランスポート層暗号化はMITM攻撃に対する十分な制御と見なされるため、クライアント側のハッシュを実装することで、TLSに依存するよりも実際に重大な脅威を軽減できるかどうかを検討する必要があります。たとえば、TLSが侵害された場合、MITMはJavaScriptを挿入してパスワードをキャプチャする可能性があります。