認証に電話網を使うのはそろそろやめよう

Published: / Last update: / Contributors:
feedback 共有

こんにちは、Azure Identity サポート チームの 高田 です。

本記事は、2020 年 11 月 10 日に米国の Microsoft Entra (Azure AD) Blog で公開された It’s Time to Hang Up on Phone Transports for Authentication の抄訳です。新着記事ではありませんが、以前より繰り返し様々な記事で参照されており、多くのお客様にとって有用であるため抄訳しました。ご不明点等ございましたらサポート チームまでお問い合わせください。


以前のブログ パスワードで攻撃は防げない - Your Pa$$word doesn’t matter では、パスワードに潜む脆弱性を明らかにしました。加えて、「でもパスワード以外の他の認証方法も侵害される可能性あるでしょ」という無数の DM や E メールに対する答えとして、君達の資格情報は全ていただいた! の記事を執筆しました。この 君達の資格情報は全ていただいた! の記事では、パスワード以外の認証方法にも脆弱性があることを概説し、FIDO、Windows Hello、Authenticator App のようなパスワードレスかつ暗号的に保護された認証方法の有用性をアピールしました。

本日、皆様が SMS と音声の多要素認証 (MFA) の仕組みはもう使うべきでない と確信を持ち、実際にそれを行動に移せるよう、その後押しをしたいと思っています。SMS と音声の仕組みは公衆交換電話網 (PSTN) に基づいており、これは現在利用可能な MFA の方法の中で最も安全性が低いと言えます。MFA の採用が増えるにつれ、攻撃者の関心は MFA をいかに突破するかに向けられつつあります。加えて、特別にデザインされた認証の仕組みがセキュリティと利便性をより高めている中で、SMS と音声の安全性の低さは際立つばかりです。パスワードレスの強力な認証へ今すぐ移行ください。Authenticator アプリを利用すれば、今すぐに安全な認証が行え、しかも進化する脅威にも対応が可能です。

繰り返しになりますが、MFA はもはや必須 です。議論は、どの MFA の方法を使用するかであり、MFA を使用すべきかどうかではありません。以前のブログにも書いたとおり「多要素認証 (MFA) は、アカウントの保護を真剣に考えているのであれば、最低限取り組むべきこととして変わりありません。パスワードに加えて何かしらのものを使えば、攻撃者のコストは大幅に増加します。このため、何らか MFA を使用しているアカウントが乗っ取られる率というのは、全体の 0.1% 以下になります。」

問題が入り込む余地が多すぎ

PSTN には、資格情報を悪用するあらゆるアプローチが適用出来てしまうのです。OTP のフィッシングも可能ですし、ソーシャル エンジニアリングも可能、アカウントの乗っ取りももちろん可能、デバイスの盗難も可能です。PSTN には他のすべての認証機器の脆弱性があり、加えて PSTN 固有の問題も抱えています。

適応性がない

PSTN のメッセージを受信するデバイスは多種多様なため、メッセージのフォーマットが限定されていることが挙げられます。メッセージのフォーマットを多種多様にしたり、長くしたりすることはできず、OTP を短いテキスト メッセージや電話で送信すること以上のことはできません。サービス提供において重要なのは、ユーザーの期待や技術的進歩、および攻撃者の行動にリアルタイムに適応することです。残念ながら、SMS と音声の形式にはこういった適応性がないため、ユーザービリティとセキュリティの観点での技術革新の余地は非常に限られています。

データが平文で転送されている

SMS と音声のプロトコルが開発された当初は、暗号化については特に検討なく設計されました。実用的なユーザビリティの観点から、これらのプロトコルに暗号化を組み込むことはできません。なぜなら、ユーザーが暗号化されたメッセージを読めなくなってしまうからです (メッセージのサイズの膨張など、既存のプロトコルにこれらを組み込めない他の理由もあります)。つまり、これは電話交換網にアクセスできる人やデバイスの無線が届く範囲内の人であれば、誰でも傍受できることを意味します。前述の 君達の資格情報は全ていただいた! の記事で述べたように、攻撃者は ソフトウェアウェアベースの無線を使用してメッセージを傍受 したり、近くの FEMTO を使用したり、SS7 傍受サービス を使用したりして電話網の通信を盗聴することが可能です。これは、PSTN システムに固有の脆弱性であり、周到に準備した攻撃者であればこういった攻撃手法も利用可能なのです。

ソーシャル エンジニアリングが容易である

ほとんどの PSTN システムはオンラインのアカウントと充実したカスタマー サポートの仕組みに支えられています。残念ながら、カスタマー サポートの担当者は誘惑、強制、賄賂、または恐喝の影響を受ける可能性があります。これらのソーシャル エンジニアリングの攻撃が成功すれば、カスタマー サポート自らが攻撃者に対して SMS または音声チャネルへアクセスさせてしまうことになります。ソーシャル エンジニアリング攻撃は E メールのシステムにも影響を与えますが、主要な E メール システム (例えば、Outlook や Gmail) は、サポート全体をとおしてアカウントの侵害を防ぐための防止策がよりしっかりと準備されています。こういったことで、PSTN システムではメッセージの傍受から、転送攻撃、SIM ジャッキングまで、さまざまなことが引き起こされます。

モバイル事業者の信頼性に依存する

残念ながら、PSTN システムには 100% の信頼性はなく、信頼性の報告自体も 100% 一貫しているわけではありません。これは地域やキャリアによりますが、メッセージが手元に届くまでの経路によって、到達までにどれくらいの時間かかるか、またはそもそも届くのか届かないのかが変わってきます。場合によっては、キャリアは配信が失敗したのに配信成功と報告することもあります。メッセージの配信に時間がかかりすぎて、ユーザーからするとメッセージが届いていないと思ってしまうこともあるぐらいです。地域によっては、配信の成功率が 50% 以下というところもあるのです。SMS は「送信したらそれでおしまい」というタイプの配信の仕組みなので、MFA のサービスを提供する事業者はメッセージの配信に関する問題の有無を確認できるようなリアルタイムのデータを持っていません。統計的な配信完了率やヘルプ デスクのコール数から問題の発生状況を類推しているのです。このことから、ユーザーに問題の発生状況を通知したり、電話網以外の代替案をお勧めしたりするのが難しいことがわかります。

規制当局による変更の影響を受けやすい

SMS におけるスパムの増加により、規制当局は識別コード、送信レート、メッセージ内容、送信許可、および「STOP」のようなメッセージへの応答に関する規制を要求しています。しかし残念ながら、これらの規制はすぐに変更されますし、地域によって一貫性がなく、大規模な配信停止を引き起こす可能性もあります (実際に引き起こしています)。配信の障害が多ければ多いほど、ユーザーの不満は増すばかりです。

一連の認証の流れを意識させづらい

SMS テキストや音声という媒体には、ユーザーに伝えられる情報量に制限があります。SMS は 160 文字、GSM を使用しない場合は 70 文字を配信できますが、エンコーディングが必要な言語になると、メッセージ分割なしではその半分程度しか配信できないのが実際のところです。フィッシングは深刻な脅威であり、ユーザーに可能な限り多くの情報を提供したい (または、Windows Hello や FIDO を使用してフィッシングを不可能にしたい) と考えていますが、SMS や音声形式は、認証が要求された際の一連の流れや詳細情報を提供する機能に制限があるのです。

他の認証方法が進化してきた

まとめますと、きっと今後皆さまも MFA を使用するようになると思いますが、問題はどの MFA を使用するのかなのです。モバイル デバイスを使用しているほとんどのユーザーに関しては、適切な答えはアプリベースの認証です。つまり弊社においては、それは Microsoft Authenticator を意味します。Microsoft Authenticator は暗号化された通信を使用しており、認証ステータスについての双方向通信を行えます。また、ユーザーが自分自身を安全に保つためのさらなる追加情報と制御機能をアプリに追加するべく開発を進めています (訳注: 2020 年当初)。2019 年だけでも、アプリ ロック、ロック画面からの通知の非表示、アプリ内のサインイン履歴の機能などを追加しました。SMS と音声通話は今後もそのまま進化しませんが、お客様が Microsoft Authenticator アプリを実際に利用しようとした際には、こういった Microsoft Authenticator アプリの新機能はさらに増えて進化し続けているのです。

PSTN を利用するのはやめて、Microsoft Authenticator を使いましょう。これだけでユーザーはより良い認証の体験がえられ、より安全になるのです。

安全にお過ごしください!

Alex (Twitter: @alex_t_weinert))

※本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。