スクリーンキーボード(OSK)を使用すると、誤った安心感が得られますか? たとえば、実際の(ハードウェア)キーボードで入力されたキーロガーがパスワードなどの情報をログに記録できないようにするためにOSKを使用する場合
以下の画像に示すように MicrosoftのOSK のように。
OSKを使用すると、下の画像のようにハードウェアキーロガーによる攻撃を防ぐことができると思いますが、OSKはソフトウェアキーロガーが情報を記録することも防ぎますか?
別の例は、HTMLおよびJavaScriptを使用して、パスワードフィールドに独自のOSKが実装されているWebサイトです
はい、それはほとんどの場合、単に役に立たない「セキュリティ対策」です。
脅威モデルを定義する必要があります。次に、オンスクリーンキーボードが適切な緩和策を提供するかどうかを定義する必要があります。
OSKは2つの脅威から保護します。
ハードウェアキーロガー
キーボードの状態のみを確認するソフトウェアキーロガー(OSKを無効にすることを試みません)。
ただし、スクリーンキーボードの実装がすべて同じではないという違いに注意する必要があります。たとえば、Windowsでは、OSKはより高いユーザーインターフェイス権限分離(UIPI)で実行できます。また、Androidでは、ハードウェアキーボードを使用する実装はほとんどないため、このようなアプリには特別な権限が必要です。
画面キーボードに実装されているアプリケーションは何ですか? ウェブサイト。
つまり、オンスクリーンキーボードの使用を強制しているユーザーは、同じ特権レベルでこれを実行しており、実行しているプラットフォーム(ブラウザ)の結果として、実際には何もできません。
現在、銀行のトロイの木馬がキーロガーを介してユーザーとパスワードを盗んでいた当時、画面キーボードは便利でした。 Webサイトの画面キーボードでは、ユーザーがキーボードでパスワードを入力しないようにすることで修正されました。その後、マルウェアはすぐに適応し、画面やマウスの周りの画像などもキャプチャして、ソリューションを克服しました。
バンキング型トロイの木馬は、10年以上にわたってこれを行ってきました。したがって、そのようなキーボードによって追加されるセキュリティは、何年もの間ほとんどゼロでした。
ユーザーがハードウェアキーロガーを使用する可能性はごくわずかなので、「アマチュアキーロガー」からのみ保護しています。
この時点で、あなたはそれがそのようなごくわずかな利益であってもなお価値があるかもしれないと考えているかもしれません。ただし、これらにもいくつかの欠点があります。
使い勝手が悪い
アクセシビリティの懸念
パスワードがショルダーサーフィンに対して脆弱になる
パスマネージャーでパスワードを入力することはできません
筋肉の記憶がない
入るのが遅い
パスワードの「入力」が難しくなるため、実際には弱いパスワードを使用することが推奨されます
私の控えめな見解では、画面キーボードを必要とするnotの決定を明確に重視しています。
optionalOSKを追加しても問題はありません。また、顧客がASCIIの範囲外の文字を含むアルファベットを使用する可能性がある場合は、実際にOSKを提供して、外部キーボードを使用するときに入力できるようにすることが適切です。しかし、これはセキュリティではなくアクセシビリティ(ただし、特殊文字の使用を間接的にサポートしています)。
攻撃者がOSKが使用される可能性があることを認識している場合(そしてそれがタッチデバイスでますます一般的になっている場合)、OSK攻撃を準備できます。例:
繰り返しますが、法律はありません。コンピュータセキュリティの1つが適用されます。
もし悪者があなたのコンピュータで彼のプログラムを実行するようにあなたを説得できるなら、それはあなたのコンピュータではなくなっています。