OTP SMS の配信と不正

OTP が証明すること

OTP が答える問いは 1 つだけです。目の前の相手は、今この番号でメッセージを受け取れるか。これはアカウント復旧やログインに役立ちます。セッションを、ユーザーが管理しているものに結び付けられるからです。しかし、本人確認書類ではありません。番号は再利用されることも、新しい SIM に移されることも、転送されることも、同じ世帯の別の人に読まれることもあります。

この区別は設計の段階で重要になります。操作の重要度が低ければ、OTP は見合った手段です。送金、パスワード変更、送金先の追加といった操作であれば、コードに 2 つ目の確認を組み合わせてください。待機時間、既存セッションでの確認、既知の連絡手段へのコールバック、あるいは手動の審査です。コードは要素の 1 つであり、判断のすべてではありません。

OTP が漏れる箇所

SIM スワップは、番号を新しいカードに移します。攻撃者は販売店やサポート窓口に自分が契約者本人だと信じ込ませ、次のコードは新しい SIM に届きます。番号の再利用は、攻撃者がいなくても同じ結果をもたらします。通信事業者が休眠番号を再割り当てし、新しい保有者が以前のアカウント宛てのコードを受け取るのです。どちらも、番号が最近 MNP で移転されたか、再割り当てされたかを確認すべき理由です。

転送や留守番電話のテキスト化は、メッセージを別の受信箱に送ります。フィッシングはフォームを複製してコードを直接収集するため、ネットワークは攻撃をまったく認識しません。ネットワーク経路上での傍受はまれで、アプリケーションの管理外にあります。実際的な対策は、コードを長くすることではなく、2 つ目の要素を加えることです。定義については OTP の用語集項目 をご覧ください。

有効な対策

1 つの番号、IP アドレス、デバイスがコードを要求できる頻度を制限してください。有効期間は短くし、コード 1 つにつき使用は 1 回とし、コードを要求したセッションに紐付けてください。送信者を登録し、本文はシンプルにしてください。マーケティングのように見えるコードはフィルタリングされることがあり、フィルタリングされたコードはログインではなくサポートチケットを生みます。

番号を信頼する前にチェックしてください。SMS を受信できない番号、最近 MNP で移転された番号、リセットの履歴がある番号には、2 つ目のステップを設けるべきです。重要度の高い操作には、既存のセッションまたは 2 つ目の連絡手段を必須にしてください。要求、送信、レシート、コード入力を別々のイベントとして記録すれば、配信の問題とユーザー側の問題を区別できます。

コードそのものも同じように慎重に設計してください。暗号論的に安全な乱数源から生成し、ハッシュを保存し、数分で失効させ、成功する使用は 1 回に限り、コードごと・セッションごとに試行回数の上限を設けてください。番号が存在するかどうかを明かさないでください。送信の前にアカウントのレコードを作成し、再試行によって完了しないアカウントが開設されないようにしてください。

送信ではなく、フローを測る

メッセージ ID が返された送信は、配信されたコードではありません。配信されたコードは、完了したログインではありません。自社で管理できるイベント、つまり送信、レシート、コード入力、成功からファネルを組み立ててください。そのうえで、プロバイダー側のデータと比較してください。自社の配信率とプロバイダーの配信率に差がある場合、端末に届かなかったメッセージではなく、自社のハンドラーに届かなかったレシートが原因かもしれません。

指標が動いたらフローを見直してください。配信率が安定したまま完了率が下がった場合は、フォーム、コードの有効期限、または送信者に原因があると考えられます。送信率が安定したまま配信率が下がった場合は、ルート、番号、またはコンテンツフィルターに原因があると考えられます。再送信が増えた場合は、配信所要時間に原因があると考えられます。変更しやすいステップではなく、データが示すステップを修正してください。

フロー全体の見直し日を設定してください。番号は持ち主が変わり、ルートは変わり、テンプレートは古くなります。立ち上げ時に機能していたフローが、同じコード、同じプロバイダーのまま、6 か月後に気付かないうちに失敗していることがあります。