web-dev-qa-db-ja.com

IDNホモグラフ攻撃について何かできることはありますか?

私は IDNホモグラフ攻撃 について読んでいて、それらに対処するためのより良い方法を考えることができません

  1. パスワードなどを求めるメールを信頼しないようにユーザーに通知する
  2. 私と同じようなすべてのドメインを購入する(高価で難しい)

他に私にできることは本当にありますか?

11
416E64726577
  1. パスワードなどを求めるメールを信頼しないようにユーザーに通知する

それは良い動きです。リンクを含む電子メールを送信しないことで、このメッセージを強化できます。唯一の問題は、多くの電子メールクライアントが、Webアドレスのように見える文字列をクリック可能なリンクに自動的に変換することです。ユーザーがブラウザにアドレスを入力してサイトにアクセスし、リンクをクリックしないようにしてください。

  1. 私と同じようなすべてのドメインを購入する(高価で難しい)

他に私にできることは本当にありますか?

ウィキペディアの記事には、 攻撃に対する防御 に関するセクションが含まれています。これらはすべてブラウザベースです。 IDNから保護するブラウザのみを使用するようユーザーに促すことができます。たとえば、Chromeのアプローチは次のとおりです。

Google Chromeは、そのすべての文字がユーザーの優先言語の1つ(および1つのみ)に属している場合にのみIDNを表示します。

2要素認証は、攻撃者がユーザー名とパスワードをフィッシングし、それらを使用して自分自身にログインするリスクを防ぐことができます。ただし、ユーザーがサイトでの認証に成功したとユーザーが思う場合、これはユーザーが攻撃者のサイトとのログインセッションで詳細を漏らすリスクを軽減するものではありません。また、攻撃者はフィッシングサイトに認証の第2要素を要求させ、ユーザーがフィッシングサイトにアクセスしたときにそれらを元のサイトに入力することができます(攻撃者がサーバーのログをチェックするのではなく、リアルタイムでフィッシングしている場合)後で)。

パスワードから特定の文字のみを要求することも簡単に回避できます。フィッシングサイトは通常、入力された2つの文字が間違っていたとだけ言ってから、完全なパスワードが見つかるまで別の2つを要求します。また、これはハッシュされたパスワードを保存できないことを意味し、通常、パスワードマネージャーはこのような動的フィールドに入力するのに問題があります。

一般にフィッシングを軽減する別のソリューションは、ブラウザベースのパスワードマネージャの使用を奨励することです。これらは、URLがパスワードマネージャーに保存されているものと一致することを確認するため、進行中のホモグラフ攻撃がある場合はパスワードを完了しません。

4
SilverlightFox

私の提案は、2要素認証を使用することです。 2要素認証を使用しないことを選択した場合は、認証ゲームを終了し、「*でログイン」を使用することをお勧めします。ここで、*はfacebook/google/yahooなどです。これにより、それをうまく行うためのお金と資源。

使用する簡単で安価な第2要素の例については、 https://stackoverflow.com/questions/5087005/google-authenticator-available-as-a-public-service を参照してください。

最後の手段として、パスワードと秘密の質問とも呼ばれる2つのパスワード方式を使用できます。 2番目のパスワードで収集するのはパスワードの特定の文字のみであり、収集する文字はログインごとに変わります。例:

Username: ......
Password: ......
3rd, 6th and 7th letter of secret Word:
          3rd .. 6th .. 7th ..

これにより、攻撃者がユーザーとしてログインするのに十分な情報を見つける前に、ユーザーが釣り攻撃に気付く可能性が高くなります。

6
David Waters
  • A 非常に基本的ですが効果的解決策は、URLを入力せずに資格情報を入力しないことを人々に知らせることです。これは多くの銀行が行うことであり、メールにリンクをまったく入れない銀行もあります。
  • 特定のドメインを自動的に入力するパスワードマネージャー(ブラウザに保存されているパスワード)は、このような攻撃に対して無防備です。少なくとも、パスワードの盗難からの保護に役立ちます。

    彼らは、ドメインがどのように表示されるか、そしてそれがlooksであるかどうかを気にしません。彼らはデータベースで実際の文字列を検索します。

  • 証明書ベースのログインは、通常、この攻撃に対して無防備です。ユーザーが攻撃サイトに「正常に」ログインしている可能性がありますが、これはnot資格情報を取得し、中間者攻撃を実行できませんでした。

4
Jens Erat

これは主にユーザートレーニングの問題です。私が支持するアドバイスは:

Save the URL for the site in your bookmarks. When logging in, open 
the bookmark, then enter your login details.

もう1つの方法は、拡張検証(EV)証明書を取得することです。スプーフィングされたドメインにはEV証明書がない可能性が高いため、ユーザーが探す際に目に見える違いが生じます。

上級ユーザー向けの1つのアプローチは、資格情報を特定のドメインに結び付けるブラウザー統合パスワードマネージャーを使用することです。パスワードマネージャーはドメインのプログラムによる比較を行っているため、ホモグラフによるなりすましに対して脆弱ではありません。

3
paj28

残念ながら、同形攻撃とその前身であるfatfinger url攻撃は、ユーザーに大きく依存しているものの1つです。ドメイン名レジストラ、証明書発行者、またはietf(asciiの何が問題なのか)に対して責任をプッシュすることもできますが、これには2つの方法が必要です。

  1. ...に対してユーザーに警告する通達。つまり、一貫したポリシーがあります。
  2. 避けられないものを軽減する方法....

あなたの予算支出に応じて、これらは本当に速く高価になる可能性があります。

2FAソリューションは、確認を行うための帯域外通信チャネルを備えているので素晴らしいですが、プロバイダーも信頼する必要があります。すべては、リスク管理と、データ損失がショーのストッパーであるかどうかにまで及びます。

1
munchkin