私の登録およびログインプロジェクト でクライアント側のパスワードハッシュを使用しました。
その目的は、HTTP要求の送信中に、受動的な攻撃者/盗聴者がユーザーのプレーンテキストのパスワードを発見するのを防ぐことです。
しかし、攻撃者はハッシュに対してブルートフォース攻撃を実行できます。そして、私はほとんどまたは少なくとも多くのパスワードがこの方法で発見されると思います、なぜならそれらは強力なブルートフォース攻撃に対して抵抗するには弱すぎるからです。
そこで、最近、非対称暗号化を使用することを考えました。
パスワードは、クライアント側の公開鍵で暗号化されます(ブルートフォース攻撃を不可能にするために、 ランダム化されたパディングを使用 )。
これは良い考えですか?
コストに見合う価値があるか?
そのようなスキームに関する問題を知っていますか?
関連情報があれば大歓迎です。
まず、私はあなたが中間者攻撃を弱めるためにこれをしていると仮定しています(安全でないHTTPを介したプレーンテキストのパスワードに関してはこれが本当に唯一の問題です)
クライアント側のハッシュにはほとんどメリットがありません。攻撃者は、ハッシュを取得するときに、ハッシュをブルートフォースする必要はありません。 serverに必要なのはハッシュだけなので、攻撃者は単にハッシュを含むPOSTリクエストを作成し、それを送信することができます。システムに入るのに平文は必要ありません。
あなたの解決策について:
すべてのクライアントに同じ公開鍵を使用している場合、状況は事実上同じです。攻撃者としてあなたが傍受する必要があるのはあなたが送信する暗号文だけであり、私は同じ暗号文を送信することであなたになりすますことができます。
各ログインで各クライアントに異なる公開鍵を与えた場合はどうなりますか?次に、中間攻撃を仕掛け、サーバーの公開鍵を自分の鍵と交換し、送信した暗号文を復号化して(これにより平文が得られます)、サーバーの公開鍵で暗号化します。
gotがあり、クライアントがどの公開鍵が正しいかを知ることができます。そのためには、何らかの信頼システムが必要になります。クライアントは、どの公開鍵がどのサーバーに対応するかを知っています。しかし、これは何百万もの公開鍵がブラウザに保存されることにつながります。したがって、何らかの証明書チェーンシステムが必要になります。そして、私はあなたが気づくと思います 私がこれで行くところ ;-)
TL; DR:HTTPSを使用します。信頼システムなしのクライアント側の暗号化は、暗号化をまったく行わないより安全ではありません。
ハッシュを破った後に他のサイトの共有パスワードが検出されるのではないかと心配している場合は、ハッシュと公開鍵暗号化の両方が適切です(Rainbowテーブルにより、公開鍵暗号化の方が優れています)。これらは受動的な攻撃者の計画を無効にするだけであることに注意してください。攻撃者がアクティブなMITM攻撃を仕掛けると、送信するJSコードを変更し、暗号化ビットを完全に削除できます。
これは私があなたの質問から理解していることです。
ここでの問題はリプレイ攻撃です。暗号化されたハッシュを盗聴した人は誰でもそれを再利用できます。
これに対する解決策は
ここで非常に重要なコンポーネントの1つは、サーバーの証明書(公開キー)がクライアントに事前にインストールされている必要があることです。クライアントがサーバーに証明書を要求して証明書を取得することはできません。