他のセキュリティメカニズムに加えてクライアント側のパスワードハッシュを行うメリット

Question

私たちは、パスワードの再利用が一般的で、インターネットユーザーのほとんどがパスワードマネージャーを使用していない世界に住んでいますが、ハッキングや侵害はより一般的になっています。これらの違反の重要性は、侵害されたWebサイトへのアクセスだけでなく、実際には、漏えいしたパスワードはソーシャルメディア、電子メール、または銀行口座に一般的に再利用され、あらゆる種類の脆弱な情報にアクセスして、被害をもたらす可能性があります。生活。問題は、高度な教育を受けたユーザーではなく、通常のユーザーに対するクライアント側の利点についてです。

TSL、強力なサーバー側ソルトハッシュ、および他のすべての種類のセキュリティ対策と組み合わせると、クライアント側ハッシュのセキュリティ上の利点はありますか？

私は複数の投稿を読んだことがあります

クライアント側のハッシュされたパスワードがパスワードになります。

そしてそれ

sslは輸送中のすべての問題を解決します

しかし、私は、サーバーを制御している誰かがパスワードを読み取ることができないシナリオを想像してみます。

しかし、弱いか再利用される可能性のあるパスワードを知らないことのメリットはありませんか？悪意のある管理者、漏えいしたログ、またはCloudflareで発生した最近のような侵害に対する追加の保護レイヤーではありませんか？

または、クライアント側のハッシュが完全に役に立たなくなるものがないですか？

さらに、ブラウザーがデフォルトでWebサイト（またはJavaScriptコード）がパスワード入力ボックスの値にアクセスできないという理想的なシナリオを想像することができます。攻撃。デフォルトのセキュリティは、選択によるセキュリティ（パスワードマネージャー）よりも優れているのではないでしょうか。

Conor Mancone · Accepted Answer

すでに述べたように、間違いなくこの質問を読むことから始めます。

サーバー側ではなくクライアント側JavaScriptのハッシュパスフレーズ-実行可能ですか？

これで最初の一連の質問に答えると思います。しかし、あなたはその質問で答えられていない追加の質問をここに持っていると思います。また、「ブラウザでハッシュ化が行われ、ハッシュ化およびソルト化されたパスワードのみがサーバーに送信された場合、またはアクセス可能な場合でも、 JavaScriptを使用しますか？」.

これはパスワード認証に対するまったく異なるアプローチであり、理論的および実用的の両方で多くの問題があると思います。

実際的な問題は単純です。ここからそこへ行く現実的な方法はありません。あなたが提案しているシステムが今実装されていると、文字通りすべてのウェブサイトが壊れてしまいます。この方法は存在しないため、この方法を使用している人はいません（ここでは明らかですが、申し訳ありません）。その結果、ブラウザーベンダーがこのようなことを実現するための新機能を徐々に導入することを想像できます。たぶん、新しい入力タイプを追加します：hashed入力タイプ？これはパスワード入力のように機能しますが、JavaScriptを介してその値を取得したり、サーバーに値を送信したりすると、ハッシュされたパスワードとそのソルトが生成されます。しかし、そのようなことは決してWeb開発者に現実的に強制されることはありません。代わりに、それを使用することを選択する必要があります。したがって、これは「デフォルトで安全」ではなく、この提案で回避しようとしている「選択で安全」と同じです。結果として、あなたがやりたいことを実際に行う方法はないと私は言います。

これを実現できた場合（おそらく、ユーザーのブラウザーを最新バージョンに更新し、Webサイトの移行に時間をかけ、古いパスワードフィールドを廃止するための協調的な努力によって）、実際に役立ちますか？私は怪しいです。問題は、ユーザーのブラウザーに密接に結合されたWebサイトのログイン手順が用意されていることです。長期的にはうまくいかないと思います。 Webアプリケーションがすでに対処しなければならないブラウザー互換性の問題の多さを考えると、アプリケーションの最も重要な部分（ログイン）を実際のブラウザーにしっかりと結合することがスムーズに進むことは本当に疑わしいです。ブラウザで使用されているハッシュアルゴリズムが非推奨になるとどうなりますか？アルゴリズムが変更されたために、ブラウザーはハッシュが変更されたことをサーバーにどのように通知しますか？ 1つのブラウザーが最新のアルゴリズムに更新されましたが（以前のアルゴリズムには弱点があったため）、ユーザーが更新されていない別のブラウザーを使用するとどうなりますか？

このような問題が、解決するよりもはるかに多くの問題を引き起こすことは予測できます。

さらに、これは全体像を見逃していると思います。パスワードをソルトおよびハッシュする全体の理由は、非常に多くの人々がサイト間でパスワードを再利用するため、リークからユーザーを保護するためです。ただし、この問題の影響を最小限に抑えるためにブラウザーベースのソリューションの実装を開始する場合は、より便利で安全な他の方法を一緒に考え出すことができると思います。あなたは間違ったツールを使って間違った問題を解決していると思います。

c-pid · Answer

@Sefaはすでに優れた読み取りを提供しているだけでなく、サーバーが悪意があり、パスワードをソルト+ハッシュしない場合（または管理者がトラフィックをインターセプトする場合）、同じパスワードを使用するのに十分なほど愚かであるという利点があります。多くのサイトでは、パスワードをクライアント側でソルトおよびハッシュすることにより、悪意のあるサーバーが他のサイトでパスワードを盗むのを防ぎます。

このシナリオに加えて、信頼できるサーバーでTLSおよび強力なサーバー側ソルトハッシュと組み合わせると、クライアント側ハッシュを使用することは考えられません。

entrop-x · Answer

「クライアント側のパスワードハッシュ」の意味がわかりません。クライアント側で通常のパスワードを取得し、最終的にそれにソルトを追加してハッシュし、新しいパスワードを「発明」して、「実際のパスワード」を使用することを単に意味しますか？または、サーバーとの対話における一種のゼロ知識証明です。これは、間違ったサーバーに接続している場合でも、パスワードを裏切らないという利点がありますか？

最初のケースでは、パスワードマネージャーと比較して、本物のユーティリティを確認できません。 saltと通常のパスワードが必要なので、saltを「マネージャー」に保存する代わりに、ランダムなパスワードを同じマネージャーに保存してみませんか？また、ソルトにエントロピーがない限り、パスワードが安全になることはありません。パスワードのエントロピーは、ハッシュしても増加しません。保存されたsaltと一般的なパスワードの使用、またはランダムな文字列をパスワードマネージャーに保存し、そのパスワードでロックを解除することの違いがわかりません。

2番目のケースははるかに興味深いものですが、パスワードの知識をゼロ知識で証明するため、サーバーの協力が必要です。