ハッシュを設定し、パスワードでログインしますか？
これまでに見たことのないパスワードハッシュ/パスワードリセット方式に遭遇しました。私は懐疑的ですが、これが悪い具体的な理由は考えられません。
アカウント作成/パスワードリセットのスキームは次のようになります。
1）ユーザーがパスワード_
"FuzzyCat"_をクライアント側アプリに入力します。2）クライアント側のアプリはパスワード
hash("FuzzyCat") -> "99476bb..."をハッシュし（おそらくサーバーからハッシュポリシー-salt、ハッシュ関数などを要求した後）、そのハッシュをサーバーに渡します。3）サーバーは、そのユーザーのパスワードハッシュとして_
"99476bb..."_をデータベースに保存します。4）ユーザーが次にログインするときに_
"FuzzyCat"_を入力すると、サーバーはそれをハッシュし、データベース内の_"99476bb..."_と比較します。
私がこれを見たユースケースは、アカウントが最初に数時間の一括処理の一部として自動化スクリプトによって作成され、その間、プレーンテキストのパスワードがメモリ内/ディスク上に浮かんでいないことです。ユーザーによるその後のすべてのログインは、安全なチャネルを介してサービスに直接行われます（注：httpsではなく、「ログブックに署名して部屋に物理的にアクセスする」タイプの安全なチャネルを意味します）。
コメントに対処するために、自動化スクリプトを信頼しない理由は、スクリプトが不変の文字列とガベージコレクションを備えた言語で記述されているため、パスワードを含むメモリがゼロ化されていないOSに返されるためです。パスワード処理のポリシー。だから、はい、主な関心事は受動的なMitMです。
質問：このスキームにはどのような脆弱性/問題があるのでしょうか？
私が考えられる唯一のことは、サーバーはクライアントが正直でハッシュポリシーに従うことに依存している必要があることです。これにより、ユーザーがデータベースに弱いハッシュを入れることが可能になる可能性があります。ログイン時に、サーバーは実際のハッシュポリシーでパスワードをハッシュし、ハッシュは一致せず、ログインも違反も発生しないため、これは大した問題ではありません。
私の知る限り、攻撃者がログインするのを助けないため、攻撃者がハッシュを取得するリスクはありません。何か不足しているのですか？
私は@Xiong Chiamiovに同意します。このアプローチには本質的に問題はありません。
一方、これは標準的なアプローチにはあまりメリットがなく（すべてのハッシュはサーバー側で行われます）、信頼できないエンティティにハッシュを開示することには明らかにリスクがあります。
元のクライアントが信頼されていない場合、クライアントは入力されたパスワードをログに記録するだけなので、明らかに何もしません。
クライアントとサーバー間の元の接続が信頼されていない場合、これは少しだけ役立ちます。真ん中の受動的な男はまだハッシュを得て、それを解読しようとすることができます。真ん中のアクティブな男がハッシュを変更してアクセス権を取得したり、ハッシュポリシーへの応答を変更して弱いハッシュにパスワードを取得させたり（またはハッシュを強制しない）、Javascriptなどを挿入して入力したパスワード）。
したがって、唯一の賢明なユースケースは、最初のサインアップ時に中間にいる受動的な男性に対する制限された緩和です。これが発生した場合は、最初のサインアップが本当に信頼されていないか、ハッシュを公開するよりも賢明なアプローチがないかどうかを確認します。
クライアント側のハッシュについて話すときに 通常は表示されます の問題は、データベースに違反した攻撃者が認証のためにハッシュをサーバーに渡すだけであるということです。ただし、このスキームでは、認証にハッシュを使用することはできません。最初のアカウント作成だけなので、そのトラップには該当しません。
私は、Apache htpasswdファイルのコンテキストでこの種のものが使用されるのを見てきました。ユーザーはダイジェストを生成し、それを比較的安全でないチャネル（電子メールなど）でシステム管理者に送信し、システム管理者はそれをサーバー構成に追加します。基本認証またはダイジェスト認証を含むシステムはコンピュータセキュリティの頂点ではありませんが、これは完全に新しいアプローチではなく、少なくともある程度の注意が払われていることを示しています。
あなたがそれを置くように説明を与えられて、私はどんな明白な問題も見ません。もちろん、認証のためにパスワードの代わりにハッシュを供給することを許すバグのような実装上の問題があるかもしれません。また、最初の接続は信頼されていないため、攻撃者がパスワードハッシュを取得する方がおそらく簡単です（パスワードハッシュを取得したり、衝突を生成したりすることができます）。しかし、それらは制度自体の問題や大きな問題ではありません。
2ニット
おそらく、サーバーからハッシュポリシー（ソルト、ハッシュ関数など）を要求した後
このメカニズムがユーザーごとのソルトを使用するか、グローバルソルトを使用するかは不明です。グローバルソルトを使用している場合、レインボー攻撃に対して脆弱です。
サーバーは、そのユーザーのパスワードハッシュとして「99476bb ...」をデータベースに保存します。
ハッシュはサーバーの外部で生成されたため、サーバーがパスワードの複雑さや長さのルールを強制する方法はありません。それらはアプリによって強制される必要があります。また、パスワードの再利用を確認する方法はありません。
提案されたスキームが追加のリスクを追加することはないと思いますが、実際にそれがいずれかのリスクを軽減しているとは思いません。重要な情報が少し不足しているようです。このスキームでは、ハッシュの設定を許可する前に、クライアントを最初にどのようにして自分が本人であるかを知るようにするにはどうすればよいですか？これが本当の課題です。MitM攻撃を防ぐためにパスワードを設定/変更して通信するさまざまな方法がありますが、認証プロセスのリモートセットアップを許可する場合、問題は、リモートユーザー。
また、監査人が気分を良くすることを除いて、この代替案が実際の利益であると考える必要があるポリシーを確信していません。現実に直面してみましょう。リスクがOSメモリからのパスワード情報の収集である場合、実際の問題は、メモリ内のものではなく、OSおよびそのメモリへのアクセスに対する適切な制御です。誰かがそのレベルのアクセス権を持っている場合は、とにかく基本認証プロセスが危険にさらされる可能性があります。ポリシーが実際に行っているのは、複雑さを追加することだけです。これにより、他の問題が発生する可能性があります。