仮想数値キーボードの上にマウスを重ねると、キーロガーから本当に保護されますか？
Banque Postale （フランス銀行）で、パスワードを入力する新しい方法を初めて見ました。仮想数値キーボードが表示され、入力するには、マウスカーソルを数値の上に置いたまま、1秒のように入力できます。
最初はこれはかなりいいように見えます。記録するキーボードストロークもマウスクリックもありません。それでも、このシステムに問題があるのではないかという不思議な印象があります。明白なのは、パスワードには数字のみを入れることが許可されているということです。他に何かありますか？
これらの種類のパスワード入力システムは、攻撃者が適応しない限り有効です。それはいくつかの行為の劇です：
- 銀行のWebサイトでは、従来の方法でキーボードから入力したパスワードを使用しています。
- キーロガーが表示され、キーストロークを収集します。
- 実際の銀行パスワード盗難のいくつかのケースの後、銀行は適応します。それらは、文字または数字でラベル付けされた一部のボタンでユーザークリックとなる「ビジュアルキーボード」を実装します。
- しばらくすると、攻撃者は適応します。新世代のキーロガーは、マウスクリック座標も記録します。これらの座標は、パスワードを再計算するのに十分です。
- しばらくして、銀行は適応します。ラベル付きのボタンを「シャッフル」するため、画面上の同じ場所に常に表示されるわけではありません。マウスクリック座標では、パスワードを再計算するのに十分ではありません。
- しばらくすると、攻撃者は適応します。次世代のキーロガーはローカルのスクリーンショットを取得し、ユーザーがクリックしたポイントの周りのピクセルを記録します。スクリーンショットは、パスワードを再計算するのに十分です。
- しばらくして、銀行は適応します。 clicksの代わりに、銀行のWebサイトは実際のクリックなしで「ホバリング」に反応します。現在のキーロガーの生成では「ホバリング」は記録されず、クリックのみが記録されるため、無効になります。
ご覧のとおり、現時点ではその時点です。何が起こるか推測できますか？
これは軍拡競争です。攻撃者は銀行に、より複雑なパスワード入力方法を適用するように強制します。銀行は、ますます「安全な」パスワード入力方法を無効にするように攻撃者を訓練します。同時に、銀行はcustomersをトレーニングして、より複雑なパスワード入力方法を処理しようとします。長期的には、攻撃者は顧客よりも速く進化するというのが私の賭けです。銀行は敗戦を戦う。
あなたが説明しているそのような保護メカニズムは、IEマウス追跡の欠陥、ブラウザがアクティブに使用されていない場合でも、攻撃者が画面上の任意の場所でマウスカーソルを追跡できるInternet Explorerの脆弱性、そして私にはそのようなパスワード保護は攻撃者がエンドユーザーのマシンに侵入してキーロガーをインストールする必要さえないため、キーボード入力を含む通常の一般的なソリューションよりも危険にさらされるリスク。
利用者がIEウィンドウを非表示にする（簡単に言うと、ポップアンダーがほとんどのユーザーに気付かれないようにする）か、スクリプトの記録を実行しているサードパーティの広告を表示するだけですマウスの動き。そのようなエクスプロイトがどのように機能するかについての情報をあまり明らかにしたくない場合は（明らかな理由により）、マウスの動きのパターンをキーパッドの使用と照合することができます。 あなたの例で投稿されたものと同様、特にユーザーは最初に静的に配置されたアクセスボタンとウィンドウに対するキーパッドの位置をクリックする必要があるため（水平方向と垂直方向の中央に配置）。これにより、キーパッドの絶対位置を簡単に計算できます。
単にマウスの動きだけを追跡することもできます。これはほとんどのユーザーに当てはまります。マウスボタンがいつクリックされたかを通知します。しかし、マウスクリックを追跡しなくても、マウスの動きを記録するだけで、ユーザーが実際に言及された銀行の口座にログインしているかどうかを計算し、その後のマウスの動きを使用して、自分のPINが何であったかを計算できます。 。
物事を短くするために、私の2セント：それにアクセスするすべてのユーザーエージェント（ブラウザ）がその機能に関して十分に安全であると見なされるまで、そのようなメカニズムに反対することをお勧めします;）
[〜＃〜] update [〜＃〜]：開発者がキーパッドの表示コードを更新し、レイアウトがランダム化されました。個々のキーは互いにシャッフルされます。もちろん、外部ブラウザーウィンドウのJavaScriptを単独で使用することで、これまで述べた特定のエクスプロイトを効果的に防ぎます。
それは完璧な解決策とは程遠く、ロングショットによっても安全ではありません;
キーは外部CGIアプリケーションを介して動的に描画され、URIパラメーター文字列とCookieに保存された一意のセッションキーによって識別されますが、リクエストフィールドが変更された場合でも、同じURLアドレスを介してアクセスできます。リファラーがなく、直接開かれます。それらは、セッションCookieの値、およびおそらくユーザーエージェント文字列に敏感であるように見えますが、後者については確認していません-
それは問題ではありません：
単一の悪意のあるブラウザープラグインは、マウスの動き、マウスのクリックを追跡し、使用されたグリフURLを読み取る（または、グリフ自体をPOST応答に添付する）ことにより）ユーザーの入力を簡単に読み取り、このすべての情報を入力されたPIN自体も非表示のフォームフィールドにプレーンテキストで保存されます（便利な名前がpassword）になり、組み込みのパスワードフィールドタイプが使用される場合よりも、単純なJavaScript呼び出しを介してその値を取得する方が簡単です。これは、通常のユーザーからhiddenであり、意味のない箇条書き記号をキーパッドの下の表示ボックスです。だれがだますのですか？関連する非表示フィールドを見つけるのに5秒もかかりませんでした。セキュリティアナリストでさえありません！これらの2行を書くのにさらに15秒かかりますJavaScriptを使用してそれを読み取り、リモートの場所に送信します。
だから、それがあります：
エンドユーザーの誤った安心感を信じて安く購入するために多くの作業が行われましたが、同時に、このまったく同じエンドユーザーはまったく何も得ていません。両方のバージョン（以前の静的レイアウトと新しいシャッフルレイアウト）は、単純にキーロガーがその名前が示すことを実行することを効果的に防止します-キーストロークのロギング（これを意味するためによくできました！）ですが、レイアウトのランダム化は他のJavaScriptの過多を防ぐために何もしません/ browserプラグインエクスプロイト。そして 特定の条件下で ユーザーが入力したPIN（特に平文で保存されたものなどのぶら下がりフルーツ）は、ブラウザやOSであってもマルウェアによって読み取られる可能性がありますもちろん、特定のブラウザは、その回答で説明されているものよりもアクティブメモリデータを悪用して読み取る方がはるかに簡単ですが、クリアテキストのパスワードをメモリに保存しないことを強く求めました。
結論：
パスワード/ PINをクリアテキストで非表示のフォームフィールドに格納し、JavaScriptの難読化の手法を採用することは、銀行が安全なメカニズムとして考慮すべきものではなく、結局のところ、安全であることをだれもだますことはできません。保護することになっている非常に同じもの。ああ、そしてもちろん、これらの変更を承認したのが誰であれ、その開発者、そして言及された銀行で働いているほとんどすべての人です。
親愛なる Banque Postale 、クライアントと将来の存在のために、車輪を再発明しようとするこれらの不用意な試みで停止し、適切なITセキュリティ専門家を雇ってください！
Thomasが言及 のように、さまざまな形式のパスワードエントリは、攻撃の形式が進化するまでパスワードを保護するだけです。
キーロガーに対するより強力な保護は、 二要素認証 を使用し、別のチャネルで異なるタイプの承認を要求することです。たとえば、銀行がワンタイムコードを携帯電話に送信し、通常のパスワードとワンタイムコードの両方を入力した場合にのみログインを許可することができます。あなたがログインするたびに、彼らはあなたに新しいコードをテキストで送って、ログインしている人が本当にあなたの電話を持っていることを確認します。
キーロガーやその他のコンピューターへの危害からの保護は困難です。 2要素認証により、キーがログに記録されていても、ログアウトすると攻撃者はアカウントを危険にさらすことができなくなります。彼らは、セッションがアクティブであるときにのみ攻撃を実行できます。これは、はるかに小さなウィンドウです。パスワードだけを知っていても、攻撃者は携帯電話に送信されるコードを必要とするため、効果がありません。
2要素認証を使用すると、パスワード攻撃の種類が進化してもアカウントは安全であり、ログインできるのは自分だけです（もちろん、スマートフォンを管理し、紛失や盗難があった場合は銀行に通知します）。 。