web-dev-qa-db-ja.com

バンキングアプリケーションのログイン情報が漏洩する

私の質問は、大手クレジットカード組織のオンラインバンキングアプリケーションに関するものです。このアプリケーションのログインプロセスは次のように機能します。

  • ユーザーが銀行のホームページにアクセスします。
  • ユーザーはユーザー名を入力してログインをクリックします。
  • ユーザー名が存在する場合は、オンラインバンキングアプリケーションにサインアップするときにユーザーが選択した固有の画像とフレーズが表示されます。画像とフレーズが期待どおりであれば、ユーザーはパスワードを入力します。
  • 正しければ、ユーザーは認証され、明細書の表示、請求書の支払い、与信限度額の増減などを含む、自分のアカウントへの完全なアクセス権を持ちます。

ここで私が見つけた問題は、ユーザーのユーザー名がわかっている場合、ユーザーがこれを最初の段階に入力して、そのアカウントの画像/フレーズの組み合わせをすぐに提示できることです。攻撃者はこの情報を簡単に使用して、そのユーザーに対するフィッシング攻撃を行うことができます。

私の質問は:

これは大きなセキュリティ上の欠陥ではありませんか?

追加:最初の回答に応答して、存在しないユーザー名を提供すると、アプリケーションは「提供されたユーザー名を確認してください」というメッセージで応答することを追加する必要があります。

6
mckiethanks

はい、これには2つの点で欠陥があります。

  1. 攻撃者は、ユーザー名を試して応答を確認するだけで、ユーザー名を列挙できます。
  2. 攻撃者は、秘密ではない情報を使用して「秘密」の画像を取得することができます。これはセキュリティの面ではまったく意味がなく、単に劇場です。

その上、別の潜在的な穴が見られます。攻撃者は画像をダウンロードする必要さえないかもしれません。必要なのが有効なユーザー名だけである場合、攻撃者が実際のサイトと同じメカニズムを使用して実際の銀行のサーバーから画像を取得するフィッシングページを作成しないようにするにはどうすればよいですか?

正しい実装は2つの認証トークンを持ち、そのうちの1つが正しく入力された後にのみ画像を表示することです。これは通常、パスワードと「シークレットワード」を介して行われますが、ハードウェアトークンのような強力な第2要素も同様に使用できます。

9
Polynomial

これの背後にある考え方は、単純な静的なフィッシング攻撃を防ぐため、フィッシングサイトを構築するために少し複雑なコードを要求するための基準を引き上げることです。 「適切に」行われた場合、画像はページ上の唯一の画像ではなく、ランダムに割り当てられたIDを持つ必要があります。理論的には、これによりページをフィッシングするためにより多くの労力が必要になりますが、実際にはページの実行を妨げないため、セキュリティの観点から特に意味のあるものは追加されません。ただし、実際には、ユーザーがイメージを引き寄せようとするフィッシングサイトを作成します。さらに読みたい場合は、トピックにニース paper があります。

より大きな欠点は、そのようなシステムでは、有効なユーザー名の写真を表示する必要があることです。有効なユーザー名に関する情報が漏洩しないように、未使用のユーザー名について一貫した画像を提示する必要があります。これははるかに大きな懸念です。画像自体は何も害しないので、画像自体はそれほど問題ではありませんが、ユーザー名の問題は、未知のもの全体を削除するため、攻撃対象が大幅に増加します。

4
AJ Henderson

Rory McCuneがリンクしたWikipediaページから:

ハーバード大学の研究では、SiteKeyが97%無効であることがわかりました。実際には、SiteKeyが見つからない場合でも、実際の人は気づかないか気にしません。

SiteKeyは、ユーザーがログイン認証情報をフィッシングサイトに開示できないように設計されています。その理由は、フィッシングサイトにはユーザーのSiteKey情報がないためです。設計の明らかな欠陥は、フィッシングサイトが正規のサイトから正しいSiteKey情報を取得し、それをユーザーに提供して、その正当性を「証明」することです。したがって、SiteKeyは中間者攻撃の影響を受けます。

また、ユーザーはより多くの認証情報を追跡する必要があります。 SiteKeyを使用するN個の異なるWebサイトに関連付けられている人は、N個の異なる4タプルの情報(サイト、ユーザー名、フレーズ、パスワード)を覚えておく必要があります。

自分でもっと上手く言えたとは思わないでください。結論として、銀行サイトのフロントページを開いたときにアドレスバーが緑色に変わらない場合(最新のブラウザーバージョンの機能は、サイトが有効で信頼性の高いEV-SSL証明書を提示したことを示しています)、入力しないでください。資格情報。サイトが個人的にあなたにその有効性を証明するために提供できるものは何でも簡単になりすましすぎます。

3
KeithS

この設定が他の認証方式よりもフィッシング攻撃に対してどのように脆弱になるかはわかりません。この認証方法はフィッシング攻撃を容易にするものではありません。偽のWebサイトに画像を表示するためにサイトにアクセスするステップを攻撃者に強制することにより、技術的に困難になる可能性がありますが、熟練した攻撃者にはこれはありません問題を実行します。

これは、ユーザーの銀行業務のセキュリティを向上させないため、良い方法ではありませんが、単純なユーザー名/パスワード認証ほど安全ではありません。

適切なスキルを持つ攻撃者が誰かの銀行のユーザー名を持ち、その電子メールアドレスの可能性が高い場合、銀行の対策に関係なく、標的型フィッシング攻撃を成功させる可能性が高いことに注意してください。

ここの主な欠陥は、@ mckiethanksがコメントで「ユーザー名を確認してください」と不明なユーザー名に応答することです。これにより、攻撃者は有用な情報、つまり最初にユーザー名を取得できます。銀行がそれを設計するためのスマートな方法は、ユーザー名が存在するかどうかにかかわらず、一連の写真ですべての試みに応答することです。

0
GdD