一部の人々はなぜクライアント側を介してセキュリティを本当に嫌うのですか？
たとえば、ウェブサイトの一般的なログインシステムを見てみましょう
- HTTPS接続が確立されました
- ユーザーはPOST経由で資格情報を送信します
- サーバー側のコードはパスワードをハッシュし、ユーザー名と一致するかどうかを確認します
- セッションが初期化され、パスワードなしで再度ログインするためのキーが発行される場合があります（「記憶」）
これは通常、現在の現状であり、パスワードはすべてサーバー上で計算されます。ただし、次のクライアント側を実行すると、それは悪い習慣と見なされます。
- HTTPS接続が確立されました
- JavaScriptがハッシュを計算します（特定のユーザーソルトを要求する場合があります）
- スクリプトはAJAXをユーザー/ハッシュ値とともに送信します
- サーバー側のコードは、パスワードのハッシュとユーザー名が一致するかどうかを調べます。
- セッションが初期化され、パスワードなしで再度ログインするためのキーが発行される場合があります（「記憶」）
誰かがこの他の方法がSSではなくCSを行うのが悪い習慣だと考えられる理由を説明できますか？どちらもSSLを介して送信し、どちらも安全なハッシュを作成します。また、どちらも認証は、適切に記述されたコードで信頼できると見なされます。どちらもXSSやその他の悪い設計の影響を受けやすくなっています。
あなたが説明したのは、システムのセキュリティを改善することではありません。意見や感情の問題ではなく、セキュリティはそのようには機能しません。あなたの例では、hash(salt+password)がパスワードになりました。 httpsを経由していない場合、攻撃者はその値を再生できます。また、実際には対処していません owasp a9 別名「ファイアシープ」スタイルの攻撃。
それはあなたが保護しようとしているものの一般的な範囲と関係があります。サーバーサイドアプリケーションを開発している場合は、ユーザーとクライアントシステムの両方からサーバーを保護しようとしています。ユーザーのシステム（つまり、クライアント）があなたの代わりにセキュリティ作業を行うようにしても、サーバーの保護を維持するのに役立ちません。通常、クライアントが何かをしているとき、たとえサーバーの要求に応じて（サーバーから配信されるJavaScriptの観点から）動作しているとしても、ハッカーはクライアント側を制御できるため、クライアントは本質的に信頼されていないという想定があります。アプリとJavaScriptとは別に入力を送信します。
サーバーはパスワードをハッシュして、パスワードストアの開示に起因する問題を抑制します。攻撃者がパスワードハッシュを取得した場合、ハッキングされたクライアントマシンからパスワードを送信してそれらを利用することは不可能であるべきです-サーバーが独自のハッシュを実行しているためサーバーが委任した場合この作業がクライアントに行われると、サーバーもセキュリティ機能を委任します。
これはすべて、保護の境界をどのように定義するかによって異なります。クライアントマシンからの脅威がまったくなく、クライアントシステムがハッキングされる可能性がないと信じる理由がある場合、この問題は解消されます...しかし、この主張を確実に行うことができるWebシステムは知りません。 。
根本的な理由は憎しみではありません...それは不安です。一般的な原則は、自分が制御できないものは何も信頼しないことです。ユーザーがアプリケーションを認証する場合、ラップトップをユーザーに提供し、そのコントロールと、それが置かれている環境のコントロールを構成しない限り、それを信頼することはできません。
従来の見方では、攻撃者がコンピュータに物理的にアクセスできる場合、攻撃者は好きなように行動することができます。
暗号化されたリンクを設定するだけの単純なブラウザでは、セキュリティが侵害される可能性はほとんどありません。厚いクライアントでは、クライアント側の機能が侵害される可能性があります。
クライアント側でハッシュを計算している場合、攻撃者が実際のパスワードではなく、ユーザーのパスワードのハッシュだけでログインできるというリスクが高まります。 （基本的にセッションごとのソルトで）パスワードをハッシュするためにナンスを送信することでそれを回避できるかもしれませんが、それでもサーバー側でそれをハッシュする必要があるので、クライアントでそれを行うのはなぜですか？ ？
あなたがクライアント側で説明するメカニズムを人々が「嫌う」かどうかはわかりません。
これは、クライアントのレガシープラクティスと不均一なサポートに関係していると思います。
まず、フォームベースの認証を介して実行する場合は、JavaScriptを実装する必要があります。 HTTPダイジェストはネイティブに同様のものを提供し、ほとんどのブラウザー（JavaScriptサポートなしのブラウザーを含む）でサポートされますが、「見栄え」がよくなく、Webサイトの一般的なブランドとうまく統合できません。公平を期すために、パスワードを入力する場所に識別可能なブランドを付けることは、セキュリティの観点からも良いことです。さらに、ブラウザーでのHTTPダイジェスト実装の主な欠点の1つは、ポップアップボックスが、保護機能を提供しないHTTP Basicを使用するものと大きく異なっていないことです。
第2に、私が知る限り、JavaScript暗号化機能のサポートはブラウザによって異なります。ブラウザー間で特定の機能のサポートが不十分であることは許容できる場合がありますが、ログインできることは非常に基本的であり、これは決して壊したくないものです。
最後に、サーバーから送信されたコードを信頼する必要があるため、とにかくHTTPS経由でログインしている場合、ここでは何のメリットもありません。 HTTPSを介してパスワードを送信する場合、パスワードをサーバーに効率的に提供し、サーバーがパスワードを正しく処理することを信頼しています。パスワードを提供するほどサーバーを信頼していない場合、認証を実行するために送信するJavaScriptでサーバーを信頼しても意味がありません。
具体的な例としては、少なくとも1つのビジネス上の理由と1つのセキュリティ上の理由があり、その方法では実現できない可能性があります。
ビジネス上の理由
- ユーザーにはJavascriptが必要です。これは必ずしも常に有効であるとは限りません。
セキュリティ上の理由
- パスワードは通常、ソルトでハッシュして保存されます。あなたはそれをあまり役に立たないでしょう定数塩のいずれかが必要になります。特定のユーザーのソルトを共有します。これにより、複雑さが増し、有用性が低下します（ただし、一定のソルトを持つほどではありません）。またはおそらくユーザー名ベースのソルト。
すべてのシステムが、あなたが説明したようなシステムの使用を避けているわけではありません。Lastpassはクライアント側でハッシュを計算します（Security Nowポッドキャスト（ transcript で説明されています）。
クライアント側でセキュリティを行うと、1つの大きな問題があります。つまり、クライアントが正常に動作すると想定します。そうでない場合はどうなりますか？つまり、ハッシュの計算を彼らに任せます...これで、計算済みのハッシュテーブルを使用して、サーバー上で超高速の速度でバンギングし、ハッシュの主な利点の1つである低速性を排除しました。そうしなくても、サーバーにクライアントのハッシュを実行させると、クライアントに何十億もの文字列をハッシュするように要求して、サーバーの速度を低下させることができます。つまり、基本的には「毒を選ぶ」ことになります。ドメイン固有の知識に基づいて答えを選択する必要があります。ユーザーを信頼していますか？それはインターネットに面していますか？そうであれば、おそらくユーザーを信頼したくないでしょう。
プロトコル分析について学ぶことは、クライアントにセキュリティ関連の多くのことをさせたくない理由を理解するためのおそらく最良の方法です。リプレイ攻撃、事前計算攻撃、それらはすべて、クライアントにあまりにも多くの自由とあまりにも多くの選択肢を与えたために起こります。プロトコルについて読んでください Needham-Schroeder-Lowe プロトコル、それがどのようにして発生したのか、どのように攻撃を発見したのか、そして何が修正されたのか、悪意のあるクライアントから安全なプロトコルを構築する方法を示す優れたデモです。
あなたの質問に答えるには、パスワードをハッシュするポイントを理解することで十分です。
パスワードがハッシュされる理由は、実際のパスワードの代わりに派生物を格納するためです。これにより、malloryがサーバーのデータベースを危険にさらしたとしても、malloryがaliceとしてサーバーにログインすることを防ぎます（非常に一般的な問題）。ハッシュされたパスワードはこのように脆弱ではないため、パスワードではなく、クレジットカード番号が公開されることについて常に耳にします。
これにより、malloryが、aliceが他のWebサイト/ソフトウェアで使用している可能性のあるパスワードを発見することも防ぎます。
ハッシュ時にソルトがサーバーで使用されるという質問に答える必要はありませんが、注意されるかもしれません。これは、ランダムなパスワードを繰り返し、一般的に使用されるハッシュアルゴリズムでハッシュしてテーブルに格納することができるため、レインボーテーブル攻撃を防ぐために行われます。 Malloryは、テーブルルックアップを実行することでパスワードを再度取得できるようになりました。これは、オペレーティングシステムのパスワードを回復するための一般的な手法です。 （少なくともWindowsはソルトを使用しません/しませんでした）。ソルトの本質は、それがインストール/ウェブサイトおよびシークレットごとに一意であることです（通常、残りのパスワードを含むデータベースではなく、php/configファイルに保存されます）。
クライアント側のセキュリティ。あなたが提案するのは、パスワードを保存する手順からステップを省略することを提案するだけなので、実際にはクライアント側のセキュリティではありません。すべてのユーザーがハッシュをパスワードとして自由に使用できることに注意してください。
理解しておくべきポイントは、接続の受信側では常にセキュリティを確保する必要があるということです（特に、公的にアクセス可能なサービスだけでなく）。 Webサーバーは誰からでも接続できるため、信頼できるものは何もありません。クライアントで発生した可能性のあるセキュリティは、一部の攻撃者が簡単にそのセキュリティをバイパスする可能性があるため、やり直す必要があります。
反例として、クライアントにもセキュリティがあることに注意してください。ブラウザが受信側の場合、ホストファイルシステムへのアクセスは、たとえばWebサイトのスクリプトに制限されます。
パーティーに遅れて申し訳ありません...
答えは大丈夫です。受け取ったハッシュをそのまま使用してデータベースと比較することにより、ハッシュを新しい「パスワード」にしました。ただし、ランダムなチャレンジ（別名「ノンス」）を追加すると、送信されたハッシュを新しいパスワードとして使用できなくなります。
クライアント側のセキュリティは悪いことだと一般化するこれらの回答には強く同意しません。私たちは何年もの間、有名なWebサイトでクライアント側のハッシュ（saltとnonceを使用）を使用しています。主に2つの理由があります。
- プレーンテキストのパスワードが誤ってサーバーログに記録されないようにする
- システム管理者の「さまよう目」がパスワードを知るのを防ぐ
クライアント側のハッシュを使用すると、ユーザーの平文パスワードにさらされることがなくなり、責任が軽減されます。
現在、システムにキーストレッチを組み込もうとしていますが、これは少し難しいことがわかります。参照 チャレンジングなチャレンジ：クライアント側のパスワードハッシュとサーバー側のパスワード検証