私はウェブサイトのユーザー登録/認証システムを設計していて、パスワードベースの認証のためにこの設計を思いついた。
これが妥当かどうか知りたいのですが。 (資格情報、oauthなどをキャッシュするためのCookieを無視します)
私がデザインに組み込んだもののいくつかは、セキュリティにどれだけ「役立つ」かわかりません。
サーバーデータベースが危険にさらされた場合、hashedPwがクライアントから送信されるため、saltedSecretを再検証できます。 (hashedPwはサーバーに保存されません)
リプレイ攻撃を防ぐためのチャレンジ(chalSecret)
scryptのコストは時間の経過とともに調整可能ですが、ブラウザーでscryptのjavascript実装を使用することを期待しているので、それほど優れた機能ではないかもしれません。
もう1つの質問は、ユーザー登録時にsaltedSecretの最初の送信を簡単に保護できるかどうかですが、HTTPSを使用するだけで十分だと思います。
これを単純化する方法があれば、教えてください。
注:この設計を簡素化する変更については、以下の編集セクションを参照してください。
編集:これを投稿してから私に起こったいくつかのこと:
私が見ている問題は、ユーザーのパスワードの送信を回避するために多くの努力をしている一方で、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を挿入してパスワードをキャプチャする可能性があります。