決済認証におけるワンタイムパスワード（OTP）とは？

ワンタイムパスワード（OTP）は、支払い認証時など、単一の認証ステップで使用される短期間のみ有効なコードです。通常、OTPを受信することは、ユーザーが登録済みの認証方法（電話番号やメールアドレスなど）にアクセスできることを示します。

OTP自体はアカウントの所有権をチェックするものではなく、プロセスを現在のデバイスやサービスに紐づけるものです。これらのコードは、短い期間有効であるか、認証に使用されるまで有効で、その後システムはそれらを無効と認識します。有効期間が短いことで、コードが複数回入力される可能性が低くなります。コードが有効な間は、もし誰かが傍受すれば、この期間内に使用される可能性があります。その結果、OTPのセキュリティは、全体的な認証プロセスにどのように組み込まれているかに依存します。

静的パスワードは、更新またはリセットを選択するまで、繰り返しログインに有効です。対照的に、OTPは1回限りの使用を目的としており、通常、入力されるか、またはその短い有効期間が終了すると無効になります。以前のセッションのOTPがすでに入力されているか、期限切れになっている場合、それらはシステムによって単に無効と認識されます。

ワンタイムパスワード（OTP）を主要な方法として使用することは特定のシナリオに対処しますが、有効期間内に異なるサイトやプラットフォームを通じてコードが入力されるようなあらゆる状況に対応できるように設計されているわけではないことに注意することが重要です。有効なコードがまだアクティブである間にそれを入手した攻撃者は、すぐに使用しようとする可能性があります。

OTPの生成とOTPの配信は別々の概念です。HOTPとTOTPはコードがどのように生成されるかを定義し、SMS、Eメール、音声はコードが配信されうるチャネルを説明します。

認証アプリはデバイス上でTOTPコードを生成でき、使用ごとに別のメッセージやネットワーク通信に依存することなく、コードをローカルで利用可能にします。また、ユーザーがコードを入力する代わりにプロンプトを介してアクセスを承認できるプッシュ認証もあります。

EMVにおいて 3-D Secure (3DS) フローの中では、システムは購入者に追加の確認を求めることがあります。発行者のアクセス制御サーバー（ACS）は取引を審査し、ユーザーの身元確認のため、さらなる手順が必要かどうかを判断することがあります。

選択肢の一つにOTPがあります。これは通常、テキストメッセージやEメールなどの登録済みのチャネルを通じてカード所有者に送信されます。その後、利用者は支払い中に表示される確認ボックスにこの一時的なコードを入力します。銀行アプリでリクエストを受け取るなど、他の方法もこのプロセスの一部として利用できます。

必要な認証が成功と確認された後、取引は支払い処理の次の段階に進みます。

一見すると、OTP、MFA、SCAはそれぞれ認証プロセスの異なる特徴を指します。以下に簡単な概要を説明します。

• OTP： 特定のインタラクション中に本人確認を支援する使い捨てコード。その分類は、関わる技術や、コードがどのようにユーザーに届くかによって異なります。
• MFA: 多要素認証つまり、知っている情報、持っているもの、または生体情報といった複数の種類の認証を用いるプロセスです。
• SCA: 強力な顧客認証. これは欧州の決済規則に基づく要件であり、通常、知識要素、所有要素、生体要素の中から選ばれる2つ（またはそれ以上）の独立した認証要素が求められます。

OTPを単独で使用した場合、認証は通常1層しか提供しないため、MFAまたはSCAの要件に準拠するには通常、他の要素と組み合わせる必要があります。ただし、OTPは多要素設定の1つの要素として機能する可能性があり、場合によっては、OTPへのアクセス方法自体に2段階目の検証ステップが必要になることがあります。
SCAの対象となるリモート電子決済の場合、認証コードを支払い金額や受取人といった詳細に紐付けるなど、さらに要件が課されることがよくあります。

OTPオプションを検討する際、 決済認証企業は通常、複数の実用的な側面を総合的に確認します。セキュリティはもとより、コードのユーザーへの到達の容易さ、既存システムへの適合性、そして実際の利用者にとっての使い心地も注目されます。
各配信方法は異なる要件を持っています。SMSと音声は通信事業者に依存し、アプリベースのコードは携帯電話会社を介さずに登録済みデバイスで動作しますが、一度限りのセットアップが必要です。
企業が実行できることの例：

• 認証ステップの成功率を追跡し、場所とチャネル別にデータを分離する。
• コードがタイムアウトする頻度、ユーザーの再試行回数、および様々な認証試行の進捗状況を記録する。
• メインの選択肢が機能しない場合に備え、利用可能な代替策を計画し、文書化する。
• 潜在的なフィッシングといった要素や、アカウント復旧時に各アプローチがどのように機能するかを評価する。
• 認証の各方法が、3DS、MFA、SCAといった適用される要件にどのように合致するかを確認する。

有用な視点を得るためには、チームはOTPコードの配信という個別の要素としてだけでなく、ユーザーの全体的な支払いプロセスにおける一つのリンクとして、認証プロセス全体を検討することがよくあります。