私たちのアプリケーションは、最近侵入テストを通過しました。テストでは、本質的に次の1つのクリティカルセキュリティ違反が見つかりました。
このレポートでは、(JavaScriptを使用して)クライアント側でパスワードを暗号化またはハッシュ化することを推奨しています。彼らは特定のスキーマを推奨することはできませんでした(彼らはクライアント証明書に言及しましたが、これは大規模なアプリケーションには非現実的かもしれません)。
投稿する前にパスワードを暗号化またはハッシュする価値はありますか?それは一般的な慣行ですか?
この推奨事項は意味がありません。パスワードのハッシュ化または暗号化に使用されるJavaScriptコードは、クライアントにも転送する必要があります。攻撃者がman-in-the-middle攻撃を仕掛けることができる場合、暗号化に使用されるJavaScriptコードを検査することもできますし、それを別のもの(暗号化しないなど)に置き換えることもできます。
暗号化の代わりにハッシュすることは、サーバーが実際のパスワードの代わりにハッシュされたパスワードを受け入れる場合にのみ機能するため、あまり意味がありません。この場合、攻撃者はパスワードを知る必要すらなく、ハッシュを知っていれば十分です。
クライアント証明書を保持するSSL中間者攻撃をマウントできないため、クライアント証明書が役立つ可能性があります(プレーンHTTPにダウングレードしても証明書は送信されません)。ただし、最初にクライアントに証明書を配布し、それをブラウザ内にインストールする必要があるため、このソリューションはクライアントが少ない場合にのみ機能します。
それとは別に:攻撃者が途中にいる場合、パスワードはまったく必要ない可能性があります。彼が必要とするのは、被害者がログインし、攻撃者が既存のセッションを引き継ぐことだけです。
このような中間者の状況を検出して、ユーザーに通知し、侵害されたネットワークからのログインを拒否できるようにすることも役立つ場合があります。接続のダウングレードを検出するためのいくつかのアイデア(つまり、httpを攻撃者に送信し、それをhttpsとして転送する):
そして、偽造された証明書で中間者を検出する方法について:
もちろん、これらすべては、特にあなたをハッキングすることを本当に決心していない攻撃者に対してのみ役立ちますが、最も簡単なターゲットを奪います。この場合、あなたがしなければならないのは、他よりも攻撃するのが少し難しいことだけです。
代わりに HTTP Strict Transport Security を実装することをお勧めします。これにより、ユーザーは最初から偽装された証明書を受け入れることができなくなります。
アクティブなMITM攻撃中に攻撃者がJavascriptコードを簡単に置き換えることができることを無視したい場合:
非対称暗号化キーを生成し、クライアントにその公開キーを提供して、クライアント側でパスワードを暗号化するために使用できます。ログインごとに新しいキーを使用すると、誰もパスワードを再発行できなくなります。