パスワードの再利用を「保護」するために、送信する前にクライアントでパスワードをハッシュするWebページがほとんどないのはなぜですか（そしてサーバー上で再度ハッシュするのですか）。

46

インターネットにはログイン情報を必要とする多くのサイトがあり、パスワードの再利用を防ぐ唯一の方法は、サーバー上でパスワードがハッシュされるという「約束」です。

したがって、パスワードを再ハッシュするサーバーに送信する前に、クライアントコンピューターで（Javascriptを使用して）パスワードをハッシュするWebページを作成するのはどれくらい難しいでしょうか。理論的には、これは追加のセキュリティを提供しませんが、実際には、サーバーでパスワードをハッシュしない「不正サイト」から保護するために使用できます。

— マルティン・フィックスマン
ソース

18

ハッシュされたパスワードは、中間者攻撃の男は「セキュリティ」のこの種を愛し、サーバは単にハッシュを比較している場合は良い平文で送信パスワードよりもされていない平文で送信

3

最適なソリューションは、（imo）クライアント側のパスワードマネージャーです。そうすれば、パスワードとしてランダムな文字列を生成でき、サーバーを「保護」することに依存しません。

— ディーンハーディング

2

@Jarrod-異なるクライアント側のハッシュアルゴリズムを使用する異なるWebサイトが、そのコミックで説明されている攻撃を防ぐように思えますが。広く再利用されている1つのパスワードは、これらの異なるハッシュアルゴリズムを介して多くの異なるパスワードになります。そのクライアント側のハッシュ計算は、安全な接続を介してハッシュを送信するなど、他の種類のセキュリティの適用を妨げません。

— Steve314

2

@ Steve314私のポイントは、クライアント上のすべてがデフォルトで侵害されていることです。クライアントで行われ、サーバーでやり取りされる場合は、ハッシュとハッシュとハッシュを行うことができますclear。その時点での数学的マスターベーションです。私が継承したシステムを修正する必要がありました。これは、あなたとOPが正確に記述する方法で設計されたもので、Wiresharkのティーンエイジャーによって常にハッキングされていました。REAL暗号化を行い、サーバーとの間のすべてのペイロードを暗号化および署名した場合にのみロックダウンし、アカウント操作は停止し、その後再び発生することはありませんでした。

5

悪意のあるサイトから身を守るための計画は、悪意のあるサイトにセキュリティの強化を依頼することです。？

— pc1oad1etter

46

なぜ使用されないのですか？それはゼロゲインのための多くの余分な仕事だからです。そのようなシステムはこれ以上安全ではありません。安全性が低いという誤った印象を与え、ユーザーが安全性の低いプラクティス（パスワードの再利用、辞書のパスワードなど）を採用するようになるため、安全性がさらに低下する場合があります。

— レインヘンリッヒス
ソース

2

これがこれまでのベストアンサーです。

1

Blu-RayやDVD暗号化のようなものです。ロックを解除するのにキーさえ必要ありません。それが提供する唯一の「保護」は、DVDが最初に出てきたとき、映画の完全なコピーを購入するよりも、コピーするディスクを購入する方が費用がかかるということでした。もちろん、今では1ドルでDVDを購入できます。さらに重要なのは、鍵が今や一般的な知識であるという事実です。同じことがブルーレイで起こっている

— マイケル・ブラウン

2

パスワードをクライアント側でハッシュすると、セキュリティが向上すると思います。私が聞いている場合、パスワードではなく、あなたのハッシュしか見ることができません。サーバーがチャレンジを送信する場合（そのとおり）、ハッシュは再利用できません。

— アンドマー

2

x4uのアプローチは、セキュリティ要件が有線でのパスワード送信と証明書の使用との間にある一部のアプリケーションに非常に適していると思います。否定的な意見の一部は、標準のサーバー側のクレデンシャル処理に加えて、パスワードがネットワークに送られる前にハッシュ化されることを見落としていると思います。したがって、質問は次のとおりです。x4uの提案は、パスワードの送信時のシナリオのセキュリティを向上させるかどうかです。私はそれを言う。これを実現する鍵は、パスワードごとのソルトの使用にあります。

— LOAS

6

MITM攻撃を防ぐ正しい方法は、エンドツーエンドの暗号化です。TLS（https）が存在します：使用します。独自の暗号化スキームを発明しないでください。

— ラインヘンリッヒス

14

理論的には、これは追加のセキュリティを提供しませんが、実際には、サーバーでパスワードをハッシュしない「不正サイト」から保護するために使用できます。

これはどの程度正確にあなたを保護しますか？やりたいことは、ハッシュされたパスワードをハッシュするだけで、それは無意味なことのように思えます。ハッシュされたパスワードがパスワードになるからです。

インターネットにはログイン情報を必要とする多くのサイトがあり、パスワードの再利用を防ぐ唯一の方法は、サーバー上でパスワードがハッシュされるという「約束」です。

複数のサイトに同じパスワードを使用しないでください。理論上、Webサイトがパスワードをハッシュする理由は、それらが侵害された場合にアカウントへのアクセスを防ぐためです。複数のウェブサイトに同じパスワードを使用するのは愚かなことです。

javascriptを使用した場合、「ハッカー」がしなければならないことは、hashed-hashed-passwordsで同じメソッドを使用することだけです。ハッシュされた情報を取得すると、データベースへのパスワード->同じハッシュの計算にかかる時間になります。これは、アカウントへのアクセスを妨げる要因です。

— ラムハウンド
ソース

1

ブラウザが常に同じ方法でハッシュする場合、はい、ハッシュは他のどこでもパスワードとして使用できます。しかし、それをハッシュしてサイトに送信する前に、ブラウザがサイト（おそらくドメイン）に基づいてソルトを割り当てたらどうなるでしょうか？面白いアイデアだと思います。

— テセレックス

2

クライアント上にある場合、セキュリティが侵害されており、クライアント上のすべてのソルトは明白に見えますが、これは非論理的な質問です。@Ramhoundの答えがわからない場合は、セキュリティで保護する必要があるコードを書いてはいけません。最初からセキュリティと暗号化について読み始めてください。

3

あなたは、元のポスターを引用している場合など、テキストの書式を設定（テキストを選択し、ちょうどエディタ上記の引用のアイコンを使用）してください

— マージャンVenema氏

1

Jarrod、あなた自身のアドバイスに従ってください、そして、あなたがばかげた主張をする前に、少しあなた自身に知らせてください。中間攻撃の男は、適切なソルト長を持つ安全なハッシュ関数に対しては役に立ちません。そして、私の提案は決して「隠蔽によるセキュリティ」ではなく、この分野の専門家によって現在知られ受け入れられていることに基づいて実際に安全であり、多くのプロトコルで同じように使用されます。これは私の発明ではなく、よく理解された手順をWebサイトのログインに適用しただけです。あなたの誤った仮定は、それらが他の多くの人にも明らかに共有されているという事実によって実質を獲得することはありません。

— -x4u

3

クライアントがソルトを知っていて、サーバーから平文で送信される場合、中間にあるものは何でもそれを知っています。クライアントのソルトを知っている場合、ハッシュを元に戻す必要があり、安全ではありません。

11

なぜなら、それは価値をほとんどもたらさないからです。ハッシュ化の理由は、データベースがハッキングされた場合、ハッカーは有効なパスワードのリストを持たず、ハッシュするだけだからです。したがって、ユーザーを偽装することはできませんでした。システムはパスワードを認識しません。

安全なのは、SSL証明書と何らかの形式の認証です。ユーザーにパスワードを提供してもらい、それからハッシュを計算できるようにします。

また、ハッシュアルゴリズムはサーバー上のより安全な領域にあります。クライアントに置くと、非表示の参照スクリプトファイルであっても、Javascriptのソースコードを取得するのは非常に簡単です。

— ジョン・レイナー
ソース

3

これが最良の答えです。トランスポート層で暗号化する必要があります。そうしないと、残りは安全ではありません。はい、暗号化関数を書くことができます...しかし、その関数は（悪意のある）エンドユーザーに見えるでしょう。SSLを使用します。

— pc1oad1etter

ハッシュアルゴリズムのセキュリティは、それが秘密かどうかに依存すべきではありません。セキュリティのためのハッシュアルゴリズムは一方向の関数である必要があります。コードがあっても、元に戻すのは困難です。それどころか、パスワード専用に設計された有名なハッシュライブラリを使用する必要があります。あまり知られていない場合は、ほぼ間違いなくバグが多いか、誤用されています。

— レーベス

6

解決策はそれよりも簡単です。クライアント証明書。マシンでクライアント証明書を作成します。Webサイトに登録するとき、クライアント証明書とサーバーの証明書を使用してハンドシェイクを行います。

パスワードは交換されず、誰かがデータベースをハッキングしても、クライアント証明書の公開鍵（セキュリティレベルを高めるためにサーバーによってソルトおよび暗号化される必要があります）だけです。

クライアント証明書は、スマートカードに保存できます（また、マスターパスワードを使用して安全なオンラインボールトにアップロードできます）。

それのすべての美しさは、フィッシングの概念を取り除くことです... Webサイトにパスワードを入力することはなく、そのWebサイトとハンドシェイクしているだけです。彼らが得るのは、秘密鍵なしでは役に立たない公開鍵です。唯一の脆弱性は、ハンドシェイク中に衝突を見つけることであり、それは単一のWebサイトで1回だけ機能します。

マイクロソフトは、WindowsでCardspaceを使用してこのようなものを提供しようとし、後にオープンスタンダードとして提出しました。OAuthは多少似ていますが、中間の「発行元」に依存しています。一方、InfoCardは自己発行できます。これがパスワードの問題の本当の解決策です...パスワードをすべて削除します。

ただし、OAuthは正しい方向への一歩です。

— マイケル・ブラウン
ソース

5

クライアント証明書は、一部のユースケースでは合理的なアプローチですが、Webサイトのログインに簡単に追加できるものではありません。ユーザーからの多大な協力が必要であり、ユーザーの秘密キーの安全性に依存します。秘密鍵の使用は、安全でも便利でもありますが、両方を同時に使用することはできません。

— -x4u

5

ここでのほとんどの返信は、クライアント側のパスワードハッシュのポイントを完全に見逃しているようです。

ポイントはありません、ハッシュをインターセプトすると、プレーンテキストのパスワードを傍受するよりも、より安全でないので、あなたがにログインしていることをサーバーに安全にアクセスします。

重要なのは、ユーザーのパスワードを保護することです。これは、ほとんどのユーザーが複数のサイトでパスワードを再利用するためです。）。

sslはmitm攻撃から保護するのに最適ですが、ログインアプリケーションがサーバー上で侵害された場合、sslはユーザーを保護しません。誰かが悪意を持ってWebサーバーにアクセスした場合、ほとんどの場合、パスワードはサーバー上のスクリプトによってのみハッシュされるため、プレーンテキストでパスワードを傍受できる可能性があります。攻撃者は、同様のユーザー名を使用して他の（通常はより価値のある）サイトでこれらのパスワードを試すことができます。

セキュリティは徹底した防御であり、クライアント側のハッシュは単に別のレイヤーを追加します。自分のサイトへのアクセスを保護することは重要ですが、他のサイトでパスワードを再利用するため、ユーザーのパスワードの秘密を保護することがはるかに重要であることを忘れないでください。

— 松葉杖
ソース

2

受け入れられた答えはあなたのポイントを非常によく共有しています。「ほとんどの返信」はそうではなく、あなたの答えがあまり価値をもたらさないため、この質問を復活させる意味はありません。

— フランク

それはおそらく答えよりもコメントの方が多いでしょう（受け入れられた答えのコメントスレッドに追加する方法を理解していないことをおologiesびします）。まだそれをブラシオフします。フィードバックをありがとう

— 松葉杖

読むのを煩わせるには長すぎるため、受け入れられた回答の境界線をフランクします。これがどのように実装されているかについての詳細が行き過ぎており、最後には利点をざっと見ています。別の答えにTL; DRがあると有益です。

— ジュール

2

@Jules：それが編集が存在する理由です。

— ロバートハーベイ

1

@JarrodRoberson私はあなたがこれ以上安全でないと混同しないと思いますか？MITMが発生した場合、サイトへのアクセスは既に放棄されていますよね？パスワードの代わりにクライアント証明書を使用しない限り、通常のユーザーにとっては非常に複雑になります。私の考えでは、クライアント側のハッシュは、各ハッシュアルゴリズムが一意であると仮定して、他のサイトで同じパスワードが危険にさらされるのを防ぎます。より安全ではないかもしれませんが、いずれにしても安全性は劣っていませんか？それで、なぜあなたはこれをそんなに強く押しますか？私はメタからこれに出くわしました、そして、これは私がこれまでに見る最高の答えです。

— zypA13510

1

それは間違いなく可能です。実際、ウェブサイトを待つ必要はありません。

見ていSuperGenPassを。ブックマークレットです。

パスワードフィールドを単に認識し、入力したものをウェブサイトドメインと連結し、ハッシュし、パスワードに「許可された」文字のみを取得するようにそれを多少変更します。

プロセスでサイトドメインを使用すると、常に同じパスワードを再利用する場合でも、サイトごとに一意のパスワードを取得できます。

それほど安全ではありません（base64-MD5）が、必要に応じてsha-2ベースの実装を完全に配布します。

唯一の欠点は、ドメインが変更された場合です。この場合、自分でパスワードを回復することはできないため、Webサイトにパスワードのリセットを依頼する必要があります。許容可能なトレードオフ。

— マシュー・M
ソース

これは、質問を読んだときに私が考えていたものです。サイトが独自のクライアント側のハッシュを行うことは実際には役に立ちませんが、それを行うブラウザ拡張機能（ドメインに基づいたソルトを使用）は、パスワードの再利用に関連するリスクを事実上無効にします。もちろん、別のマシンからログインしようとすると楽しい部分があります

— ...-アーロンノート

3

これは、パスワードを平文で渡す他のどのスキームよりも安全ではありません。パスワードが一意になりますが、暗号化されませんが、途中にサーバーがある場合は、複雑でありながらクリアなパスワードを取得して、必要なだけ使用できます。変更されません。ハッシュは魔法の弾丸ではなく、暗号化でさえなく、暗号化ハッシュと呼ばれますが、それが暗号化であることを意味するものではありません。パスワードがクライアントであるか、またはクライアントが知っている塩をpassword含むSHA-256であるかどうかは関係ありませんpassword。中間接続者はそれをキャプチャできます。

@Jarrod Roberson：もちろんパスワードを使用できますが、別のアカウントに再利用することはできません。これがポイントです。したがって、私が接続しているWebサイトの1つが彼のパスワードベースを盗まれ、それらを平文で保存した場合、他のアカウントは安全です。

— マチューM.

@Aaronaught：それが実際に輝く場所です。送信されるパスワードは、ユーザーがログオンするWebサイトドメインと選択したマスターパスワードから取得されるため、ブックマークレットがあれば任意のコンピューター（およびブラウザー）からログインできます。これが、証明書よりもやや快適な理由です。

— マチューM.

6

@Jarrod：これはサイトのセキュリティ対策ではなく、ユーザーのセキュリティ対策です。誰もがこのようなスキームを使用した場合、パスワードの再利用は問題になりません。MITMスキームでは、クライアントハッシュされたパスワードを使用して、そのサイトにアクセスできますが、そのサイトのみにアクセスできます。そこに改善があります。通常、パスワードは再利用される可能性が高いため、1つのパスワードを単純に解読するだけで多くのアカウントにアクセスできるようになるはずです。この場合、クラックされたパスワードは、発見されたサイトまたはデータベースに対してのみ有効であることが実質的に保証されています

— 。– Aaronaught

0

私はX4uの答えが好きですが、私の意見では、ブラウザ/ html仕様に統合する必要があります。現時点では答えの半分にすぎません。

ここに私がユーザーとして抱えている問題があります。データベースに保存されたときに、パスワードがもう一方の端でハッシュされるかどうかはわかりません。私とサーバーの間の行は暗号化されている可能性がありますが、宛先に到達するとパスワードがどうなるかわかりません-おそらくプレーンテキストとして保存されます。データベース管理者はデータベースを販売することになり、あなたがそれを知る前に世界中があなたのパスワードを知っています。

ほとんどのユーザーはパスワードを再利用します。彼らはこれ以上何も知らないからです。技術的な人たち。15番目のパスワードに達すると、ほとんどの人は書き留めていない限り、それらを覚えておく機会に耐えられないからです（誰もが知っていることも悪い考えです）。

ChromeまたはIEまたは私が使用しているものは、サーバーが生成したソルトを使用してパスワードボックスがクライアント側でハッシュされ、パスワード自体を効果的にサンドボックスすることを教えてくれる場合、ユーザーとして再利用できることを知っているでしょうリスクの少ないパスワード。私はまだ暗号化されたチャンネルが欲しいだけでなく、送信中に軒が途切れることを望んでいません。

ユーザーは、パスワードをサーバーに送信することさえできず、ハッシュのみであることを知る必要があります。現在、X4Uのソリューションを使用している場合でも、そのテクノロジーが使用されているかどうかわからないため、これが事実であると知る方法はありません。

— クリス・ネヴィル
ソース

1

これはブラウザのダイジェスト認証に統合されており、httpでやり取りされたパスワードをハッシュ化して追加情報を取得し、サーバーで確認するための前後の手順が表示されます。

— gbjbaanb

-1

フレームワーク、CMS、フォーラムソフトウェアなど、インストール先のサーバーを制御しないようなものを構築するときに使用するのに適した方法だと思います。つまり、はい、ログインとログインアクティビティには常にSSLの使用を推奨する必要がありますが、フレームワーク/ cmsを使用しているサイトにはSSLがないため、この恩恵を受けることができます。

他の人が指摘しているように、ここでの利点は、MITM攻撃で他の誰かがこの特定のサイトにログインすることを許可できなかったということではなく、その攻撃者が同じユーザー名/パスワードのコンボを使用して、アカウントを持っている可能性のある数十の他のサイトにログインします。

このようなスキームは、ランダムなソルト、またはサイト固有のソルトとユーザー名固有のソルトのコンボでソルトする必要があります。これにより、パスワードを取得したユーザーは、他のサイトの同じユーザー名に使用できません（同一のハッシュスキームを使用するサイトでさえも））、または同じパスワードを持っている可能性のあるサイトサイトの他のユーザーに対しても。

他のユーザーは、ユーザーが使用するサイトごとに一意のパスワードを作成するか、パスワードマネージャーを使用することを提案しています。これは理論上は健全なアドバイスではありますが、現実の世界でこれを当てにするのは愚かであることは誰もが知っています。これらのことのいずれかを行うユーザーの割合は小さく、私はそれがいつかすぐに変わるとは思わない。

サイト所有者とエンドユーザーの両方が過失である場合、javascriptのパスワードハッシュは、フレームワーク/ cms開発者が移動中にパスワードを傍受する人の被害を制限するためにできることです（最近のWiFiネットワークでは簡単です）セキュリティについて（おそらくそうです）。

— matthewv789
ソース