入力時にパスワードを確認するサイトがセキュリティリスクをもたらす可能性はありますか？
使用しているサイトの中には、ログイン（not登録）フォームに入力するときにパスワードを確認するものがあります。したがって、たとえば、最初に私が持っている可能性があります：
Username: sapi ✓
Password: passw ×
そして私がタイプし終えたときまでに、サイトは間違いがなかったことを私にすでに知らせています：
Username: sapi ✓
Password: password123 ✓
実際にログオンするには、フォームの送信が必要です。
これがクライアント側で行われていないと仮定しましょう（たとえば、ハッシュアルゴリズムとターゲットハッシュをクライアントに通知することにより）。このようなアプローチは、任意のユーザーのハッシュを取得できるため、明らかに安全ではありません。
通信が暗号化されていると仮定すると、入力時にパスワードを文字ごとに確認できるため、セキュリティ上のリスクが発生しますか？
私が懸念する主な領域は、そのために同様の（サブ）文字列を繰り返し送信することです。
- いくつかのオーバーヘッドデータ+パスワードの最初の文字
- いくつかのオーバーヘッドデータ+パスワードの2文字目
- ...
- オーバーヘッドデータ+パスワード全体
これにより、各通信の平文はある程度確定的になります（少なくとも、前の通信と次の通信の平文に関連します）。
一部の暗号化アルゴリズムは既知のプレーンテキスト攻撃に対して脆弱であることは知っていますが、SSLがその1つであるかどうかはわかりません。また、ここで得られた知識のレベル（既知の平文攻撃よりも明らかにはるかに低い）が出力のエントロピーを減らすのに十分かどうかもわかりません。
私は2つの質問があると思います：
- これは標準のWeb暗号化アルゴリズム（基本的にはhttps）のセキュリティリスクですか？そして
- そうでない場合、これmightが問題を引き起こすアルゴリズムのクラスはありますか？
質問に、登録フォームではなくloginフォームについて言及していることを明確にしました。言い換えると、クライアントは、JSを使用して、既知の長さ/複雑さのルールに対してパスワードを単純に検証することはできません。アカウントは既に存在し、チェックマークは正しいパスワードに対してのみ表示されます。
現代の暗号システムは、一般に、既知の平文攻撃の影響を受けません。暗号化アルゴリズムに関しては、基本的にTLSで一般的に使用されている3つのアルゴリズムがあります。
- AES
- RC4
- DES（3DES）
これら3つはすべて、既知の平文攻撃に耐性があると考えられており、そのような攻撃について十分に研究されています。
私が気になるのは、サイドチャネル攻撃です。パスワードについて（潜在的に）漏えいする情報がいくつかありますが、私が考えることができるすべての情報には、トラフィックを監視できる攻撃者が必要です（もちろん、あなたが尋ねた既知の平文攻撃も同様です）。
TLS圧縮が有効になっている場合（実際には無効にする必要があります CRIME攻撃 の場合）、攻撃者はリクエストで送信された他のすべてのデータを正しく推測できます（ある場合は難しくありません）一意のCookieではありません）。部分文字列を送信し、パスワードと同じ長さに圧縮されている文字列を確認することで、パスワードを把握できる可能性があります。
タイミング攻撃。キーストロークと入力パターンを入力した後、JavaScriptがサーバーにリクエストを送信する速度に応じて、攻撃者はパケット間の間隔に基づいて、入力している文字を識別（または少なくとも絞り込み）できます（これは、キーストローク間の間隔）。この攻撃は実証されました Songに対して、Songほかによる 2001年に攻撃されたため、まったく新しいものではなく、HTTPSの新しいものです。 （HTTPSは一般にリアルタイムではありませんが、あなたが説明しているものはほぼリアルタイムです。）
パスワードの長さ。攻撃者は、サーバーに送信されたパッケージの数とそのサイズを測定し、入力された文字の数から長さを推測する可能性があります。パスワードの長さを知ると、ベースが1減少します。したがって、攻撃者は11 ^ 5個のパスワードを推測する代わりに、数字のパスワードに対して10 ^ 5個のパスワードを推測するだけで済みます。
全体として、これは私が心配することではありません。このWebサイトがXSS、SQLインジェクション、セッション管理の脆弱性などに対して脆弱である可能性ははるかに高いです。それは、攻撃者がこの往復技術を使用してアカウントを侵害するよりもはるかに脆弱です。
他に何もない場合、それは時間遅延なしにパスワードをチェックするためのAPIです。それはそうでなければなりません：もし彼らがすべての不正確な推測の後に時間の遅れがあったなら、それはパスワードをライブチェックするポイントを無効にするでしょう。パスワードが「password」の場合、サーバーは正しいパスワードに到達する前に7つの誤ったパスワードをチェックする必要があり、キーを押すたびに遅延を許容することはできません。ユーザーは別の場所からパスワードをカットアンドペーストすることでこれを回避できますが、これは推奨する動作ではありません。
同様の理由で、このAPIは、ほぼ間違いなく、誤った推測を繰り返してもユーザーをブロックしません。たとえそうであっても、しきい値はおそらく許容できないほど高くなります。マルウェアベースのクラッカーは、ここで特にうまく機能します。ユーザーのハードドライブをこすってパスワードを探し、カット/ペーストをエミュレートすることで、長さの代わりに、パスワード全体に対して1つの推測だけを無駄にします- 1推測。
この種のチェッカーを実装する人々は意味がありますが、その背後にある概念には根本的な欠陥があります。誰もそれをしてはいけません。あなたは悪意のある攻撃に身をさらしているだけで、実際のUXの利益はありません。
ばかげた質問かもしれませんが、入力したパスワードがサイトのパスワードポリシーの最小要件を満たしているという意味で✓を受け取っていないと確信していますか？クライアント側のコードが「はい、これは有効なパスワードであり、私はまだ正当性を検証していませんが、それを受け入れます」と言っているように。 「password1234」としてパスワードを入力しても、それはまだ✓ですか？
ここにサーバーの問題があります。サーバーが重いものを持ち上げている間に、ブルートフォースクラックを試すことができます。十分に強力なサーバーの場合、攻撃者は（クライアント側の）コンピューティングコストがほとんどまたはまったくなくても成功する可能性が高くなります。サーバーが弱すぎる場合は、サービス拒否攻撃のためのニースチャネルを開きます。
前回チェックしたとき、結果を返す前に小さな（ランダムな）スリープを導入することをお勧めしました。入力した各文字のパスワードをチェックすることは、これから逆方向に機能するようです。
不完全なパスワードがサーバーに送信される理由はありません。クライアントはパスワードの規則（8文字、数字を含める必要があるなど）を知っており、それを検証してユーザーにステータスを表示できます。リクエストを送信する前