ログインフォームから送信する前のパスワードのクライアント側ハッシュ
私のウェブアプリケーションがログインフォームから暗号化されていないパスワードを送信していることに気づきました。それはまさにそのようなものです-私は分析しました、ユーザーがログインフォームから送信した文字列はサーバー側でMD5でハッシュされ（それ自体は間違っていますが、それは別の話です）、その後比較されます（DBのパスワードはハッシュされます） ）。
私は内部の問題トラッカーで問題を提起しました。これは、Javascript libを使用してログインフォームでパスワードを直接ハッシュすることで置き換える必要があるため、プレーンテキストで送信されることはありません。私は開発者の1人からすぐにコメントを受け取りました。これはユーザーがJavaScriptを有効にする必要があるため、これは誤りです。また、この問題は、クライアント側でパスワードをハッシュするのではなく、HTTPSを使用して解決する必要があります。
この "Javascriptを有効にする必要があります"がらくたについては個人的な意見がありますが、現時点では重要ではありません。しかし、私は明確な答えを得たいと思います。ユーザーに自分のパスワードをサーバーに送信するよりも、JavaScriptを有効にすることを本当に強い罪ですか？また、アプリケーションがHTTPSサーバーではなくHTTPで実行される状況についてはどうでしょう（多くの理由により）？
攻撃者の立場から見ると、同じテキストを送信することでドアのロックが解除される限り、プレーンテキストのパスワードまたはMD5ハッシュを送信するか、それとも大きな違いはありません。パスワードの正確な値を取得するのではなく、取得することが主要な目的であることに注意してください。そのため、攻撃者がハッシュされたパスワードを傍受した場合、パスワードを自分のボックスから再度送信すると、同じ結果が得られます-ログインが受け入れられます。 HTTPSを使用すると、すべてのデータが保護されるため、最善のソリューションです。
編集：あなたのアプリケーションがプレーンなHTTPを介してアクセスされる状況に関しては-まあ、あなたはそれで台無しにされます。独自のプロトコル（NOT RECOMMENDED）をロールしてパスワードをクライアント側で暗号化し、サーバー側で復号化、ハッシュ、および検証しない限り、パスワードは公開されます。
とにかくhttpsを有効にする必要があり、ログインフォームでhttpを使用しないでください。開発者が言っていることは、パスワードがクリアテキストでフォームに送信される場合でも、アプリケーションがhttpsのみとして提供されるように制限することで（Webサーバーで構成する必要があります）、トラフィック全体が暗号化されるため、パスワードは安全です。それは正しいです。ブラウザでパスワードをハッシュしてからhttp経由で送信したとしても、盗聴や盗用が可能です。攻撃者にとって-この場合、盗まれたハッシュは実際のパスワードと同じくらい良いです。レインボーテーブルで検索できない場合でも、ログインリクエストでハッシュを送信できます。
私の意見では、javascriptを使用する場合と比較して、ハッカーが専門知識を必要としない（つまり、サーバーからクリアテキストパスワードを盗聴する）ため、クリアテキストパスワードを送信することは大きな罪でありリスクです。また、代わりにCookieを保護してみませんか？ Cookieをhttponlyとしてマークしたくないですか？