SiteKeyはフィッシングに対する有効な防御策ですか？
ここ で説明されているように、一部の銀行はフィッシングに対する防御を提供するためにSiteKeyメカニズムを使用しています。 （これは、ユーザーがユーザー名を入力した後、パスワードを入力する前に、パーソナライズされた画像（各ユーザーが独自のカスタム画像を持っている）がユーザーに表示されるスキームです。理論的には、これにより、ユーザーがBOAにあることを確認できるようになります。ページ、フィッシングサイトではありません。）コメントと回答は、このアプローチに関するいくつかの問題を示していますが、その質問は、アプローチが効果的であるかどうかに関するものではありませんでした。
同じスキームの使用を検討している可能性のある将来の訪問者のために、サイトで質問をしたいと思います。
これはフィッシングに対する正当な防御ですか？多分それ自体ではなく、多層防御戦略の1つのステップとして、またはこれは誤った安心感を与えますか？もしそうなら、それは単に役に立たないのでしょうか、それともmoreこのスキームを採用するのは危険ですか誤った安心感のため？
SiteKeyはフィッシングに対する効果的な防御策ではありません。原則として、画像の調査に非常に注意を払い、Webセキュリティがどのように機能するかを知っているエキスパートユーザーのごく一部のユーザーには役立ちますが、これらのユーザーはまれです。ただし、このようなメカニズムは、コンピュータセキュリティの専門家だけでなく、平均的なユーザーを保護するために本当に必要です。また、一般的なユーザーにとって、SiteKeyは以下で説明する理由により、フィッシングに対する効果的な防御策ではありません。
良いニュースは、今日、フィッシングはリスクの規模では比較的低いようです。フィッシング攻撃は今日、あまり成功していないようです。したがって、SiteKeyの欠陥は許容できる場合があります。とは言っても、SiteKeyはほとんどセキュリティシアターです。一般的なユーザーにとっては、それほどセキュリティは追加されません。
どうすればこのような強力な発言を行うことができるかについて詳しく説明する必要があります。偶然にも、この問題は研究文献で研究されており、実験データがあり、そのデータは魅力的です。データは私たち全員にとっていくつかの驚きを持っていることがわかりました！
実験的な方法論。カスタムの「セキュリティイメージ」（およびセキュリティフレーズ）のSiteKeyの使用は、尋ねられた一般ユーザーを対象に実施されたユーザー調査で評価されていますラボでオンラインバンキングを実行します。彼らには知られていないが、安全に動作するかどうか、セキュリティイメージが役立つかどうかを確認するために、制御された方法で「攻撃」されたものもあった。
研究者は2つの攻撃を評価しました：
MITM攻撃：研究者たちは、SSLを取り去る中間者攻撃をシミュレートしました。攻撃の目に見える唯一の兆候は、HTTPSインジケータの欠如です（アドレスバーにHTTPSがない、ロックアイコンがないなど）。
セキュリティ画像攻撃：研究者たちはフィッシング攻撃をシミュレートしました。この攻撃では、SiteKeyセキュリティイメージ（およびセキュリティフレーズ）が欠落していることを除いて、ユーザーが実際の銀行サイトを操作しているように見えます。その代わりに、攻撃は次のテキストを配置します。
SiteKeyメンテナンス通知：Bank of Americaは現在、受賞歴のあるSiteKey機能をアップグレードしています。 24時間以内にSiteKeyが表示されない場合は、カスタマーサービスにお問い合わせください。
これは素晴らしい攻撃だと思います。ユーザーに表示するセキュリティ画像（またはセキュリティphprase）を理解しようとするのではなく、セキュリティ画像をまったく表示せず、セキュリティ画像がなくても問題ないことをユーザーに説得してください。最強のセキュリティシステムを破ろうとしないでください。土台を弱めることで全体をバイパスするだけです。
とにかく、研究者たちは、ユーザーがこれらの方法で攻撃されたとき（ユーザーの知らないうちに）の行動を観察し始めました。
実験結果結果は？攻撃は信じられないほど成功しました。
1人のユーザーがMITM攻撃を回避したわけではありません。 MITM攻撃にさらされたすべての人がそのために失敗しました。 （彼らが攻撃を受けていることに気付いた人はいません。）
セキュリティイメージ攻撃にさらされた人の97％がそれに当てはまりました。この攻撃を受けた場合、3％（60人の参加者のうち2人）のみが安全に動作し、ログインを拒否しました。
結論。この実験からいくつかの教訓を引き出しましょう。
まず、SiteKey（およびセキュリティイメージ）は無効です。 SiteKeyは、非常に単純な攻撃手法によって簡単に打ち負かされます。
第二に、どのセキュリティメカニズムが効果的であるかを評価するとき、私たちの直感は信頼できません。セキュリティの専門家でも、間違った結論を導き出す可能性があります。たとえば、セキュリティイメージは攻撃者に一生懸命働き、MITM攻撃を実装するよう強制するため、セキュリティイメージはある程度のセキュリティを追加すると主張する、有能で知識豊富なセキュリティ担当者もいます。この実験から、この議論は水を保持しないことがわかります。実際、非常に単純な攻撃（Webサイトのクローンを作成し、セキュリティイメージを、メンテナンスのために現在セキュリティイメージ機能がダウンしているという通知で置き換える）は、実際には非常に成功しています。
したがって、システムのセキュリティがユーザーの行動に依存する場合、一般ユーザーが実際にどのように行動するかを評価するために厳密な実験を行うことが重要です。私たちの直感と「第一原理」分析は、データの代わりにはなりません。
第3に、通常のユーザーは、セキュリティ担当者が望むとおりに振る舞わない。時々私達はプロトコルについて「ユーザーはそのようなことをし、サーバーはそうしたことをし、ユーザーが何かの逸脱を検出した場合、ユーザーは彼が攻撃を受けていることを知るだろう」と話します。しかし、それはユーザーの考えではありません。ユーザーは、セキュリティ担当者が持っているような疑わしい考え方を持っておらず、セキュリティが彼らの最前線にいるわけではありません。何かが正しくない場合、セキュリティの専門家は彼女が攻撃を受けていると疑う可能性がありますが、それは通常のユーザーの最初の反応ではありません。通常のユーザーは、Webサイトが不安定であることに慣れているため、奇妙なまたは異常な何かを目にしたときの最初の反応は、それをすくめて、インターネット（またはWebサイト）が正しく機能していないと想定することです。瞬間。したがって、特定のキューがない場合にセキュリティメカニズムがユーザーを疑って疑わしいと考える場合、それはおそらく不安定な理由によるものです。
第4に、SSLロックアイコンのようなセキュリティインジケータがないことにユーザーが気づくことを期待するのは現実的ではありません。私たちは皆、子供の頃「サイモンは言う」を演奏したと確信しています。ゲームの面白さは、それを気にかけることを知っていても、「Simon Says」の手がかりがないことを見逃しやすいことです。次に、SSLアイコンについて考えます。オンラインバンキングを実行する場合、SSLアイコンを探すことはユーザーの主要なタスクではありません。代わりに、ユーザーは通常、請求書を支払って家事を済ませて、もっと便利なものに移動したいだけです。そのような状況で、その不在に気付かないと、はるかに簡単になります。
ところで、バンクオブアメリカ（または同様の方法を使用する他の銀行）がこれらの調査結果にどのように対応したのか疑問に思われるかもしれません。結局のところ、バンクオブアメリカはユーザーにSiteKey機能を強調しています。では、セキュリティイメージ機能は実際にはほとんど役に立たないという発見にどのように反応しましたか？回答：そうではありません。彼らはまだSiteKeyを使用しています。そして、彼らに彼らの反応について尋ねると、典型的な反応は「まあ、私たちのユーザーはSiteKeyを本当に気に入って感謝している」という形の何かでした。これは何かを教えてくれます。それは、SiteKeyがセキュリティシアターの一種であることを示しています。どうやら、SiteKeyは、実際に深刻な攻撃から保護するだけでなく、ユーザーにプロセスを快適にさせるために存在しています。
参考資料。上記で要約した実験の詳細については、次の研究論文を参照してください。
- 皇帝の新しいセキュリティインジケーター 。スチュアートE.シェクター、ラクナダミヤ、アンディオズメント、イアンフィッシャー。 IEEE Security＆Privacy 2007。
答えはいいえだ。その理由は、通常SiteKeyと呼ばれるこのスキームが中間者攻撃またはMITM攻撃に対して脆弱であるためです。ユーザー名とその他の「事前認証」情報（アカウントの管轄など）を入力した後、サイトが表示するものはすべて、フィッシングサイトによって実際のサイトから取得できます。フィッシングサイトがしなければならないことは、実際のサイトに連絡して、入力した内容を入力するだけです。フィッシングサイトは、そのサイトから「秘密の」フレーズまたは画像を受け取り、それをあなたに渡すことができます。次に、そのサイトは本物だと考え、パスワードを入力します。
スキームは多少改善される可能性があります。おそらく、使用されているデバイスに関する一意の識別情報を含む暗号化されたcookieを設定し、ユーザーが定義できる方法でサイトの正面玄関を変更します。それはMITMが偽装することは困難ですが、依然として脆弱であり、Cookieの有効期限が切れたり、ユーザーがキャッシュされたCookieをクリアしたりすると、データは失われ、実際のサイトはその方法を使用して実際のサイトであることを証明できなくなります。
フィッシングに対する最善の防御策はすでに存在しています。信頼できるX.509証明書を使用してサイトに署名し、あなたが本人であることを第三者が確認できるようにします。証明書が適切に暗号化およびハッシュされている場合、なりすましは事実上不可能であり、ユーザーのブラウザーアドレスを緑色にするHTTPSセッションを確立するために使用できます（ユーザーが正しい場所にいることを示す視覚的なフィードバックが提供されます）。
主なリスクは、そのようなメカニズムが一般に、サイトが実際にサイトであることを知る方法としてユーザーに提示されることです。この点で、フィッシングサイトは単にクライアントとして機能し、ページから情報を取得して再表示する可能性があるため、意味のあるセキュリティは提供されず、ユーザーにも説明しないでください。実際、説明がなくても、多くのユーザーは、そのようなカスタマイズを、そのサイトが正しいサイトであることを証明するものとして、それを使用する他の主要なサイトからの説明であると考えています。これにより、最小限の複雑さでより効果的なフィッシング攻撃につながる可能性があります。
とはいえ、適切なユーザー教育を行うことは、サイト管理者にとってフィッシング検出に有益な機能となる可能性があります。それはフィッシング攻撃の技術的なレベルを少し上げ、それを使用しているサイトがフィッシャーがどこから来ているのかを知ることができないようにするために、より包括的な攻撃を必要とします。とはいえ、真ん中の男が正当なホストから情報を引き出すことは依然として可能であり、豊富なボットネットリソースがあれば、に一致しないさまざまなIPアドレスから画像を要求することが可能です。標的とされた機関が攻撃に関する意味のある情報を取得するのを防ぐためのフィッシングサイト（フィッシングの試みが検出されるたびに1つのボットを焼き付けることになります）。
全体的に、私は個人的には適切なユーザー教育がユーザーにサイトの信頼性のはるかに優れた指標であるSSL証明書をチェックするように教えることができるので、それが有益な利益につながる多くの状況があるとは思いません。知識ベース認証（少なくともSiteKeyスタイルの実装では）は、教育を受けていないユーザーにとって本当に「有用」であり、そのコンテキストでは完全に失敗します。