web-dev-qa-db-ja.com

SMS 2段階認証は廃止する必要がありますか？

Google、Facebook、およびほとんどの重要なWebサイト（銀行、支払いサイトなど）SMS as major認証（2段階認証の場合）またはアカウントの制御（パスワードのリセットなど）の方法。

ただし、すでにかなり前に、GSMテクノロジーが次の脆弱性を公開していることが証明されています。

これにより、SMS対応サービスは本当にハッキング可能であるという決定につながります（はい、それはいくらかのお金とリソースを必要としますが、時間が経つにつれてすべてが安い）。したがって、問題は次のとおりです。

  • あなたがどれほど重要な人物であるか、

  • 攻撃者があなたを攻撃するためのリソースを費やすだけの意思がある場合。

だから私は3つの質問があります：

  1. 予見可能な将来とは何ですか？世界中のGSMプロバイダーがすべての脆弱性をすぐに修正し、テクノロジを簡単にアップグレードしますか？計画されていない場合、どうすればよいですか？

  2. 使用するサービスプロバイダーに、そのメソッドを無効にできることをどのように伝える必要がありますか？ （現時点では、アカウントのすべての場所から電話番号のエントリを 削除 する場合、GoogleとFBのみが電話番号を2-FAとして削除できますが、このような重要なサービス、LastPass、Authyなど...はまだ許可されていません）

phonesms
10
T.Todua

Bruce Schenierがこの問題について話します here 。

記事を引用する。

ここでは、2つの新しいアクティブな攻撃が確認され始めています。

  • 中間者攻撃攻撃者は偽の銀行のWebサイトを作成し、ユーザーをそのWebサイトに誘導します。ユーザーが自分のパスワードを入力すると、攻撃者はそのパスワードを使用して銀行の実際のWebサイトにアクセスします。正しく行われると、ユーザーは銀行のWebサイトにアクセスしていないことに気付くことはありません。次に、攻撃者はユーザーの接続を解除して、ユーザーが望む不正なトランザクションを実行するか、ユーザー自身のトランザクションと同時にユーザーの銀行取引を通過させます。
  • トロイの木馬攻撃。攻撃者はユーザーのコンピュータにトロイの木馬をインストールします。ユーザーが銀行のWebサイトにログインすると、攻撃者はトロイの木馬を介してそのセッションに便乗し、必要な詐欺的なトランザクションを実行します。

二要素認証では何も解決されないのをご覧ください。最初のケースでは、攻撃者はパスワードの絶え間なく変化する部分を、変化しない部分とともに銀行に渡すことができます。 2番目のケースでは、攻撃者はユーザーのログインに依存しています。

2faの問題は、パスワードとotpの両方が盗聴されることです。または、単にパスワードが盗聴された後、ユーザーが「ここをタップしてログイン」プロンプトをタップします。どちらかが攻撃者を許可します。

defalt で述べたように。ユーザーを認証する（数学的に言えば）適切な方法は、yubikeyの セキュリティキー のように強力な相互認証を使用することです。

1）予見可能な将来とは何ですか？世界中のGSMプロバイダーがすべての脆弱性をすぐに修正し、テクノロジーを簡単にアップグレードすることは起こりますか？そして、もし彼らがこれを計画しないなら、私たちは何をすべきでしょうか？

ロックインのため、変更に非常に長い時間がかかります。 Ipv4は2010年までに死亡すると予測されていました。2019年には ipv6の使用量 は約25％です。ローリングコードは1980年代に作成されましたが、固定コードシステムは2019年にまだ出回っています。そのため、smsは今後も長い間使用されます。

あなたができる最善のことは、ウェブサイトが利用できる最も強力な認証を利用することです。個々のユーザーがそれ以上にできることはあまりありません。強力な認証を実装するかどうかは、Webサイト次第です。

2）インターネットの予見可能な未来とは-GOOGLE、BANKSなどすべてがSMS認証をすぐに廃止する傾向があります。そうしないと、それは起こりません。それでも、＃1の問題が引き続き発生します。 ？

GoogleとYubicoは、2つの方法でインターネットのユーザー認証のアップグレードに取り組んでいます。 1.ハードウェアベースのトークンを配信し、2。Webサーバーが webauthn を実装しやすくする。これら2つの方法は、実際には同じコインの異なる側面です。

3）そして最後の注意として、もちろん、私たちの現実では、2ステップ認証（SMSベース）は、ほとんどのハッカーからのセキュリティを向上させます（つまり、パスワードが盗まれた場合）が、現実は2を使用するユーザーであることが判明しました-step sms承認（または、2stepを使用しないが、回復方法として自分の携帯電話番号をプロファイルに入力した）は、セキュリティ上の脅威を増大させます-たとえば、ハッカーがパスワードを知らないが、smsをハッキングできる場合（代わりにセキュリティを強化した場合のハッカーの最初のカテゴリとは対照的です）。かなり問題の多いジレンマ。

チェーンは、最も弱いリンクと同じくらい強力です。誰かのアカウントを直接ハッキングしたり、アカウントを「復元」したりするほうが簡単な場合。攻撃者は気にしません。 Webサイトは、ユーザーを認証する強力な主要な方法と、回復を実装することを選択した場合に必要です。それも安全である必要があります。

4
silverduck

ユーザーの側に「バイイン」がないので、それはその場所を維持すると思いますIE彼らはそれを使用する前にデバイスでアクションを完了する必要はありません。私は使っていませんSMS 2FAを使用すると、2FAを使用しない場合よりもセキュリティが低下することを示唆するデータに出くわします。

1
they

そして、もし彼らがこれを計画しないなら、私たちは何をすべきでしょうか？

ERPソフトウェアの2FAを実装する際の経験を共有します。

  • Authenticator-app based 2FAを提供します。
  • 可能であれば、モバイルアプリをサポートしている場合は、2FAをモバイルフィンガープリントと統合します。 。
  • レガシーな理由や要件のためにSMSベースの2FAを提供する必要がある場合は、セットアッププロセス中にエンドユーザーにメッセージを表示することにより、アプリベースの2FAがより良い選択であることを明確にしてください。 （はい、会社の敷地内にスマートデバイスを持ち込めない会社があります）
    • B2Bの場合、通常、このようなポリシーは会社のITチームによって決定されます。 SMSベースの2FAを使用する場合の長所/短所/セキュリティリスクを明確に伝えるようにしてください。
  • 銀行の場合、2FAにはアプリベースまたはハードウェアトークンを使用することをお勧めします。
    • 例：シンガポールのDBSは、トークンを生成するためのハードウェアデバイスを顧客に提供します。まず、SMSが6〜8桁のOTPで携帯電話に送信されます。このOTPをデバイスに入力して、2番目の要素を検証するために使用される別のOTPを生成する必要があります。

そうは言っても、上記のすべての方法にはいくつかのトレードオフがあります。 （使いやすさとセキュリティ）

セキュリティが高すぎると、ユーザビリティが低下する可能性があり、ユーザーが知らない場合はセキュリティが低下します。

  • 私が覚えているのは、私が数か月間会社でインターンをしていたときに、ユーザーが毎月パスワードを変更することを強いられ、小文字1文字、大文字1文字、特殊文字1文字の8文字のパスワードで、最後の10個のパスワードを設定することができないというものでした。これにより、ユーザーはパスワードに次のようなパターンを持つことになります：Jan012018。一部のユーザーは、自分のパスワードが付いた付箋さえ持っていました。

すべての可能性を検討し、ユースケースに基づいて採用することをお勧めします。

gOOGLEやBANKSなどは、SMS認証をすぐに廃止する傾向があります

上記のように、銀行は第2要素のより安全な方法に向かって動き始めています。もちろん、普遍的になるには時間がかかります。
（私が覚えていることから、Googleはアプリベースの2FA、ハードウェアトークン、および2FAの他の方法もサポートしています）

1
Procrastinator