パスワードの再利用を「防ぐ」ために、送信する前にクライアントでパスワードをハッシュするWebサーバーがほとんどない（そしてサーバーでそれらを再度ハッシュする）のはなぜですか。
インターネット上にはログイン情報を必要とするサイトがたくさんあります。パスワードの再利用を防ぐ唯一の方法は、パスワードがサーバー上でハッシュされるという「約束」ですが、常にそうであるとは限りません。
ですから、パスワードを再ハッシュするサーバーに送信する前に、クライアントコンピューターで（Javascriptを使用して）パスワードをハッシュするWebページを作成するのはどれほど難しいのでしょうか。理論的には、これは追加のセキュリティを提供しませんが、実際にはこれを使用して、サーバーでパスワードをハッシュしない「悪質なサイト」から保護することができます。
どうして使わないの？なぜなら、それはゼロゲインのための多くの余分な仕事だからです。そのようなシステムは、より安全ではありません。 less安全な場合もあります。これは、より安全であるという誤った印象を与え、ユーザーが安全性の低い方法（パスワードの再利用、辞書のパスワードなど）を採用するようになるためです。
理論的には、これは追加のセキュリティを提供しませんが、実際にはこれを使用して、サーバーでパスワードをハッシュしない「悪意のあるサイト」から保護することができます。
これはどの程度正確にあなたを守っていますか？やりたいことは、意味のないハッシュ化されたパスワードをハッシュ化することだけのようです。ハッシュされたパスワードがパスワードになるからです。
ログイン情報を必要とするインターネット上のサイトはたくさんあります。パスワードの再利用を防ぐ唯一の方法は、パスワードがサーバー上でハッシュされるという「約束」ですが、常にそうであるとは限りません。
複数のサイトで同じパスワードを使用しないのはどうですか。理論上、ウェブサイトがパスワードをハッシュ化する理由は、侵害された場合にアカウントへのアクセスを防ぐためです。複数のWebサイトに同じパスワードを使用するのは、ばかげています。
JavaScriptを使用した場合、「ハッカー」がしなければならないことは、hashed-hashed-passwordsに同じメソッドを使用することだけです。ハッシュ化された情報を取得したら、データベースへのパスワードから同じハッシュを計算するのにかかる時間は、アカウントへのアクセスを妨げる要因になります。
それは価値をほとんど追加しないからです。ハッシュ化の理由は、データベースがハッキングされた場合、ハッカーは有効なパスワードのリストを持たず、ハッシュのみを取得するためです。したがって、ユーザーを偽装することはできません。システムはパスワードを認識していません。
安全なのは、SSL証明書と何らかの形の認証です。ユーザーからパスワードを提供して、ハッシュを計算できるようにしたいと考えています。
また、ハッシュアルゴリズムは、より安全な領域のサーバー上にあります。それをクライアントに置くと、たとえ隠された参照スクリプトファイルがあったとしても、JavaScriptのソースコードを取得するのは非常に簡単です。
解決策はそれよりも簡単です。クライアント証明書。自分のマシンにクライアント証明書を作成します。 Webサイトに登録すると、クライアント証明書とサーバーの証明書を使用してハンドシェイクが行われます。
パスワードは交換されず、誰かがデータベースをハッキングしたとしても、クライアント証明書の公開鍵（サーバーがソルト化して暗号化し、セキュリティを強化する必要があります）しかありません。
クライアント証明書はスマートカードに保存できます（マスターパスワードを使用して安全なオンライン保管庫にアップロードできます）。
それのすべての美しさはそれがフィッシング詐欺の概念を取り除くことです...あなたはウェブサイトにパスワードを決して入力しない、あなたはそのウェブサイトとただ握手しているだけです。彼らが得るすべてはあなたの公開鍵であり、それは秘密鍵なしでは役に立たない。唯一の影響は、ハンドシェイク中に衝突を見つけることであり、それは単一のWebサイトで1回だけ機能します。
MicrosoftはWindowsでこのようなものをCardspaceで提供しようとし、後でそれをオープンスタンダードとして提出しました。 OAuthは多少似ていますが、中間の「発行者」に依存しています。一方、InfoCardは自己発行される可能性があります。これがパスワードの問題の真の解決策です...パスワードを完全に削除します。
OAuthは正しい方向への一歩です。
ここでのほとんどの返信は、クライアント側のパスワードハッシュの要点を完全に逃しているようです。
重要なのはnotです。これは、ログインしているサーバーへのアクセスを保護するためです。ハッシュを傍受することは、プレーンテキストのパスワードを傍受することよりも安全ではないためです。
重要なのは本当に安全なことですユーザーのパスワード。ほとんどのユーザーは複数のサイトでパスワードを再利用するため、通常は個々のサイトのログインアクセスよりもはるかに価値があります（そうすべきではありませんが、実際にはそうです）したがって、振る必要はありません）。
sslはmitm攻撃からの保護に最適ですが、サーバーでログインアプリケーションが侵害された場合、sslはユーザーを保護しません。誰かが悪意を持ってWebサーバーにアクセスした場合、パスワードはサーバー上のスクリプトによってのみハッシュされるため、プレーンテキストでパスワードを傍受できる可能性があります。その後、攻撃者は同様のユーザー名を使用して、他の（通常はより価値のある）サイトでそれらのパスワードを試すことができます。
セキュリティは多層防御であり、クライアント側のハッシュは単に別のレイヤーを追加します。自分のサイトへのアクセスを保護することは重要ですが、他のサイトでパスワードを再利用するため、ユーザーのパスワードの機密性を保護することははるかに重要です。
それは間違いなく可能であり、実際にはウェブサイトを待つ必要はありません。
SuperGenPass をご覧ください。ブックマークレットです。
それは単にパスワードフィールドを認識し、入力したものをWebサイトドメインと連結し、ハッシュし、パスワードに「許可された」文字のみを取得するようにそれを多少変形し、それから初めて、ハッシュされたパスワードがネットワークに送信されます。
プロセスでサイトドメインを使用することにより、常に同じパスワードを再利用する場合でも、サイトごとに一意のパスワードを取得できます。
非常に安全ではありませんが（base64-MD5）、必要に応じてsha-2ベースの実装を完全に配布します。
唯一の欠点は、ドメインが変更された場合です。この場合、自分で回復することができないため、パスワードをリセットするようにWebサイトに要求する必要があります...それは頻繁には起こりません。許容できるトレードオフ。
私はX4uの答えが好きですが、私の意見では、ブラウザー/ html仕様に統合する必要があるようなものです-現在のところ、それは答えの半分にすぎません。
ここに私がユーザーとして抱えている問題があります-私のパスワードがデータベースに保存されているときに、もう一方の端でハッシュされるかどうかはわかりません。私とサーバーの間の行は暗号化されている可能性がありますが、宛先に到達するとパスワードがどうなるかわかりません。おそらくプレーンテキストとして保存されます。データベース管理者はデータベースを販売することになり、それを知る前に世界全体があなたのパスワードを知っているかもしれません。
ほとんどのユーザーはパスワードを再利用します。彼らはよりよく知らないので非技術者。 15度目のパスワードに到達すると、ほとんどの人は書き留めない限り、それらを覚えておくことができないためです（誰もが知っていることも悪い考えです）。
ChromeまたはIEまたは私が使用していたことが何であれ、パスワードボックスがサーバー側で生成されたソルトを使用してクライアント側でハッシュされることになるとすぐにわかる場合そして、パスワード自体を効果的にサンドボックス化します。ユーザーとして、リスクを減らしてパスワードを再利用できることを知っています。暗号化されたチャネルが必要であり、送信中に盗聴が発生しないようにしたいと思います。
ユーザーは自分のパスワードをサーバーに送信することさえできないことを知っている必要があります-ハッシュだけです。現在、X4Uのソリューションを使用していても、そのテクノロジーが使用されているかどうかが分からないため、これを知る方法がありません。