クライアント側のパスワードセキュリティ手法のメリット

Question

私は、サーバー側でSSL/TLSとハッシングとソルトのパスワードの利点を理解しており、おそらくbcryptでパスワードセキュリティにこの標準を採用する予定です。

ただし、上記のベストプラクティスと組み合わせてクライアント側のJavaScriptを使用してサーバーにルーティングする際に、パスワードの暗号化または難読化のメリットがあるかどうかは疑問です。私がこれについて考えるのを正当化するのに使用した理由は、管理者のエラー（mod-rewriteまたはfaulty vhost設定を有効にしない）が将来、私のサーバへのHTTPS以外の接続を許可する可能性があるということです。これは、何らかの形でSSL/TLSなしで接続を管理すれば、パブリックWi-Fiでユーザーを保護するための追加のセキュリティレイヤーになります。

もう一度、このアプローチにメリットがあるかどうかと、そうでない場合は、なぜですか？

EDIT：さらに、ログインフォームが受信されていても（クライアントサイドのJavaScriptでデコードされ、DOMを介して表示されるエンコードフォームサーバー側をエンコードしていても）少なくとも偽装していることが考えられます公衆無線LANでプレーンテキスト取引を狙っているだけの人物に対して。

Answer 1

このような方法は、攻撃者が最もカジュアルになるのを助けるかもしれませんが、ほとんどすべての努力に値するものではなく、実際には全体のセキュリティに多少の悪影響を及ぼす可能性があります。

サーバがこの難読化された/ハッシュ/暗号化されたパスワードをユーザのパスワードとして受け入れる場合、それを盗むことは、攻撃者にユーザの平文パスワードを盗むのと同じくらい多くの利点を与えます。彼らはユーザーとして認証することができます。彼らは、難読化された文字列からユーザーの平文パスワードを取得することさえできるかもしれません。なぜなら、難読化するためにユーザーのパスワードに対して実行された操作を正確に見ることができるからです。

さらに、ログインフォームを難読化することはほとんど無意味です。関心のあるオンスを持つ攻撃者はネットワークトラフィックのログインシーケンスを見つけることができ、ユーザーの情報を盗み出すことができるようになります。それは、羊のスニファの壁のようなものをだますかもしれませんが、あなたがログインシーケンスを検出するためのルールを書こうと思っている限り、誰かのために必要とする限りです。十分なユーザーベースを所有している場合や、アプリケーションが機密情報を扱う場合は、非常に短時間です。

要するに、既に解決済みの問題を解決しようと時間を無駄にしないでください。あなたが排他的なHTTPSを正しく設定していることを確認してください。

Answer 2

ので、読書をたくさんやった後、私は、この技術は何のメリットを持っていない理由の以下の説明をまとめました：

複雑さはセキュリティの敵です。システムの将来の保守担当者が難読化の方法を完全に理解していない場合、実際の業界標準のセキュリティ技術に加えて、実際のセキュリティを提供する代わりに、実際のセキュリティを提供していると考え始める可能性があります。

これに加えて、TLSが失敗するまで誰もこの難読化を回避しようとは思わなかったという点で、私の考えは間違っていました。排他的TLSが将来失敗した場合のTLS障害より先に難読化を解決するには信じられないほどの利点があるので、これは真実ではないでしょう。

このテクニックは、保護がほとんどないために追加コストがかかり、最悪の場合、セキュリティが強化されてしまうという幻想を引き起こし、システム管理者に適切なTLSを保証することに注意を払う可能性があります。