シェア:
){kind=small}
KarlはVonageのDeveloper Advocateで、RubyサーバSDKのメンテナンスとコミュニティの開発者エクスペリエンスの向上に注力しています。彼は学ぶこと、ものを作ること、知識を共有すること、そして一般的にウェブ技術に関連することが大好きです。
Vonage APIを使用した2FA SMS詐欺の軽減
所要時間：1 分
通信技術は日進月歩であり、その変化のスピードは近年急速に速くなっている。この進化は、これらのテクノロジーを活用するビジネスに多くの利益をもたらし、顧客とのインタラクションの向上やインテリジェントな自動化を実現している。残念ながら、技術トレンドの変化を悪意のある理由で利用しようとする悪質な行為者も存在する。その一例が、SMS 2FA詐欺の増加である。
SMS経由の二要素認証(2FA)は以前からありましたが、ここ数年で人気が急上昇しています。最近では、ほとんどのアプリケーションが2FAを提供しており、多くの場合、SMS通信チャネルを使用して実装されています。この人気のため、2FAシステムは、非正規のトラフィックを経由させるなど、様々な方法でこれらのシステムを悪用しようとする詐欺師にとって、ある種の魅力となっている。
この種の詐欺行為の一般的な動機は、プレミアム・レート番号または詐欺師が非公式なプレミアム番号として作成したバーチャル番号にメッセージをルーティングすることである。この詐欺がどのように行われるかを理解するために、まずSMS経由で2FAを実装するための典型的なハイレベルのワークフローを説明しよう。
顧客がアプリケーションにサインアップするか、アカウントを作成する。
サインアップ/アカウント作成プロセスの一環として、顧客は2FA目的で使用する携帯電話番号を指定する。
2回目以降のログインでは、2FA認証の一環として、SMSが番号に送信され、顧客がアプリケーションUIから入力できるコードが記載される。
このような基本的なワークフローは、プレミアム・レート番号にトラフィックをルーティングするような、非正当なトラフィックに基づく詐欺に対して脆弱である可能性がある。詐欺を行うには、ステップ2でプレミアム・レート番号を入力する。その後、詐欺師は、ボットを使って、このアカウントまたはそれに続くアカウントに複数回ログインするようシミュレートする。各「ログイン」時に、ステップ3の2FAシステムの一部として、プレミアム・レート番号にSMSが送信されるため、各メッセージに通常のメッセージのコストをはるかに超える追加コストが発生する。詐欺師は通常、ボットを使って複数のアカウントにサインアップし、各アカウントで複数の2FA SMSメッセージをトリガーする。そのため、このような詐欺の金銭的コストは、すぐにかなり大きくなる可能性がある。
この種の詐欺を軽減する方法はいろいろある。
一つのアプローチとして、様々な要因に基づいて、所定の期間内に送信される検証 SMS メッセージの数を制限することが考えられる。例えば、同じ番号や同じIPアドレス、デバイスIDに送信されるメッセージの数を制限する。
レート制限はこのような詐欺の影響を軽減することはできるが、完全に否定することはできないかもしれない。同様に重要なのは、2FAのセットアップのために提供された番号の衛生チェックを実行し、詐欺の原因そのものを防ぐことである。これは、強固な入力検証によって達成できる。
先ほどのハイレベルのワークフローを見ると、ステップ3が不正の影響が発生する場所だが、この影響の可能性は、プレミアム・レート番号が2FAに使用される番号として設定される、より前のステップ2で生まれる。サインアップワークフローのこの時点で入力検証を行うことで、プレミアムレート番号がステップ3にルーティングされるのを防ぐことができる。入力検証を組み込んだ最新のワークフローを見てみよう：
顧客がアプリケーションにサインアップするか、アカウントを作成する。
サインアップ/アカウント作成プロセスの一環として、顧客は2FA目的で使用する携帯電話番号を指定する。
指定された数字は、事前に設定された特定のパラメータと照合される。これらのパラメータに照らし合わせて、その数値が許容できると判断されれば追加され、そうでなければ拒否される。
2回目以降のログインでは、2FA認証の一環として、SMSが番号に送信され、顧客がアプリケーションUIから入力できるコードが記載される。
詐欺の可能性のある番号を識別するために使用される正確なパラメータは、アプリケーションの顧客ベースによって異なる。一般的なアプローチは、特定の番号がどの国から発信されたかを識別するために、国の通話コードまたは番号プレフィックスを使用することである。
この種の番号情報は、いくつかの方法で利用できる：
特定の国の番号のみを許可する。この方法は、例えば、プレミアムレート番号の規制レベルが高く、この種の詐欺の可能性がはるかに低い特定の国からすべての顧客が発信されることがわかっている場合に便利です。
特定の国からのNumbersを防ぐ 特定の国特定の国からの番号を防止する。 さらに、プレミアムレート番号の詐欺が知られている、または番号詐欺に対する金銭的なキックバックが蔓延している（プレミアムレート番号に対する規制が緩やか、または全くない）国など、詐欺リスクの高い国もあります。
余談だが、このような不正入力はボットによって行われることが多いため、CAPTCHAを導入することで、不正行為の一部を防ぐことができる。
番号識別情報を取得する方法として、Vonage Number Insights APIがあります。これを行うには、適切なAPIエンドポイントにリクエストを送信します。ベーシック、スタンダード、アドバンスドインサイトには異なるエンドポイントがあり、それぞれ番号に関する異なるレベルの情報を提供します。違いの概要は このドキュメント.また API仕様もある。
Number Insights APIは、Vonage SDKを経由して使用することもできます。以下は、Node.js SDKを使用して、Advanced Insightsエンドポイントを介して番号の情報を取得する例です。
vonage.numberInsight.get({level: 'advancedSync', number: '447700900000'}, (error, result) => {
if(error) {
console.error(error);
}
else {
console.log(result);
}
});
APIへのリクエストからの典型的なレスポンスは次のようなものだ：
{
"status": 0,
"status_message": "Success",
"lookup_outcome": 0,
"lookup_outcome_message": "Success",
"request_id": "55a7ed8e-ba3f-4730-8b5e-c2e787cbb2b2",
"international_format_number": "447700900000",
"national_format_number": "07700 900000",
"country_code": "GB",
"country_code_iso3": "GBR",
"country_name": "United Kingdom",
"country_prefix": "44",
"request_price": "0.03000000",
"remaining_balance": "1.97",
"current_carrier": {
"network_code": "23410",
"name": "Telefonica UK Limited",
"country": "GB",
"network_type": "mobile"
},
"original_carrier": {
"network_code": "23410",
"name": "Telefonica UK Limited",
"country": "GB",
"network_type": "mobile"
},
"valid_number": "valid",
"reachable": "reachable",
"ported": null,
"roaming": "unknown"
}このレスポンスには、以下のようなNumbersに関するデータポイントが含まれている。 country_code, country_code_iso3および country_prefixなどの番号に関するデータポイントが含まれている。国に関するデータだけでなく、その他のデータも不正の可能性がある番号を示すことがある。A network_typeの undefinedまたはバーチャル・ナンバーを暗示するものは、時には指標となることがある。もう一つの有用なデータポイントは reachableプロパティである。 unknownまたは "reachable"以外の値を持つ場合、不正な番号の可能性を示している可能性がある。
Number Insights APIを組み込んだ最新のワークフローは次のようになる：
顧客がアプリケーションにサインアップするか、アカウントを作成する。
サインアップ/アカウント作成プロセスの一環として、顧客は2FA目的で使用する携帯電話番号を指定する。
Number Insights APIにHTTPリクエストを行い、この番号に関する情報を取得する。
応答中のデータを使用して、事前に設定された特定のパラメータに照らし合わせて番号をチェックする。これらのパラメータに照らし合わせて、その番号が受け入れられると判断された場合、その番号は追加され、そうでない場合は拒否される。
2回目以降のログインでは、2FA認証の一環として、SMSが番号に送信され、顧客がアプリケーションUIから入力できるコードが記載される。
Number Insight APIを使用して詐欺の可能性のある番号を特定することは、詐欺の軽減という点ではすぐに効果が得られますが、このアプローチは残念ながら全体的な影響という点ではやや限定的です。Numbers Insightsが提供する情報は、個々のプロバイダーに大きく依存している。例えば、国全体をブロックすることは、たとえその国から発信された番号の方が詐欺行為のリスクが高いとしても、ビジネス上の理由から選択できない場合がある。
より長期的で包括的な軽減策を提供できるもう一つのステップは、Vonage Conversion APIを介した堅牢なルーティング・データへの貢献である。
変換API Conversion APIを使用すると、2FA通信の信頼性と品質についてVonageに伝えることができます。
コンバージョンとは、2FA の文脈では、顧客に送信された認証コードが実際に使用されたか どうかの尺度である。使用された場合、これはコンバージョンとみなされる。
詐欺師の目的はコードを実際に使用することよりもSMSが送信されることなので、2FAの低いコンバージョンレートは通信リンクにおける詐欺的傍受の強力な指標となり、攻撃されたルートを特定するのに役立ちます。Conversion APIを使用すると、コンバージョン率のデータをVonageのAdaptive Routing™アルゴリズムに送り込むことができ、トラフィックを不正の影響を受けたルートから影響を受けていない別のルートに迂回させることができます。Adaptive Routing™ アルゴリズムは、SMS や音声通話を配信するために、特定の瞬間に最適なキャリア・ルートを自動的に決定します。
ハイレベルのワークフローでは、Conversion APIはステップ3で登場する。顧客がアプリケーションに認証コードを入力すると、このアクションの詳細を、アクションに関連するウェブフック経由で受け取ることができる。典型的な 2FA ワークフローのより詳細な概要は この文書.高レベルのワークフローの目的のために、更新されたバージョンは次のようになるかもしれない：
顧客がアプリケーションにサインアップするか、アカウントを作成する。
サインアップ/アカウント作成プロセスの一環として、顧客は2FA目的で使用する携帯電話番号を指定する。
Number Insights APIにHTTPリクエストを行い、この番号に関する情報を取得する。
応答中のデータを使用して、事前に設定された特定のパラメータに照らし合わせて番号をチェックする。これらのパラメータに照らし合わせて、その番号が受け入れられると判断された場合、その番号は追加され、そうでない場合は拒否される。
2回目以降のログインでは、2FA認証の一環として、SMSが番号に送信され、顧客がアプリケーションUIから入力できるコードが記載される。
顧客が認証コードの入力に成功したことを関連する Webhook 経由で確認したら、関連する message-id を含む HTTP リクエストを Conversion API に送信します。
Conversion APIを導入する準備ができましたら、担当のアカウントマネージャーまたは営業までご連絡ください。