PSD2：EUでの強力な顧客認証
公開: 2018-05-23これは、PSD2：EUにおける強力な顧客認証（SCA）の詳細を説明する3部構成の一連の投稿の2番目です。
この3部構成のシリーズの最初の記事では、PSD2（Second Payment Services Directiveの略）と呼ばれる欧州連合の欧州銀行監督局（またはEBA）指令を紹介し、強力な顧客認証（またはSCA）の基本原則のいくつかを概説しました。 。
SCAについて、EBAは次のように述べています。「PSD2のおかげで、消費者は電子決済や取引（オンラインバンキングの使用やオンライン購入など）を行う際の保護が強化されます。 パート1で述べたように、規制技術基準（RTS）は、強力な顧客認証（SCA）を、自分の支払いアカウントにアクセスするため、およびオンラインで支払いを行うための基礎にします。」
この投稿では、実装者が考慮しなければならないSCAの制限と規制当局について説明します。 まず、生成される認証コードを見てみましょう。 これは基本的に2要素認証または2FAであることを忘れないでください。
RTSは、認証コードの次の条件の概要を示しています。
- 認証コードの開示から、知識、所持、継承に関する情報を引き出すことはできません。 これは、認証コードを知っている場合、他の知識項目（たとえば、ユーザーID）、ユーザーが所有しているもの（たとえば、携帯電話-携帯電話番号を取得できないことを意味します）を取得する方法がないことを意味します。または継承–バイオメトリクスなど、ユーザー自身に関する側面。
- 以前に生成された他の認証コードの知識に基づいて新しい認証コードを生成することはできません。 この条件では、認証コードが与えられた場合、1つまたは複数の以前の認証コードを参照して新しい認証コードを生成する方法はありません。
- 認証コードを偽造することはできません。 実装者は、偽造または偽造されたコードを正常に検証できないように、認証コードを作成する必要があります。
- コードの有効期間内に、5回を超えて失敗した認証の試行を試行する必要があります。 生成された各コードには、有効期限または「存続時間」があります。 このタイマーは、コードが生成された直後に開始され、配信時間が含まれます。 経験則として、コードは15分以内に期限切れになるはずです。 一部の組織ではこれに30分または1時間かかりますが、これは長すぎる可能性があります。 ユーザーがコードで認証を試みて5回失敗した場合は、新しいコードを送信する必要があります。 これにより、あらゆるタイプのブルートフォース攻撃がコードを理解しようとするのを防ぎます。
- オンラインで支払いアカウントにアクセスするために認証された後、支払人またはユーザーによる活動がない最大時間は、5分を超えてはなりません。 これは標準の非アクティブタイマーであり、認証コードとは別に、ユーザーが正常に認証されてアクティビティを実行しないと開始するタイマーです。
これらはすべて、2FAの状況で使用される認証コードの生成/検証のための比較的標準的な条件です。
次に、トランザクションのダイナミックリンクと呼ばれるRTS要件を見てみましょう。 電子リモートトランザクション（たとえば、デバイスがデスクトップまたはモバイルデバイスであるかどうかに関係なく、インターネット経由で行われる）には、「トランザクションを（支払いの）特定の金額および特定の受取人に動的にリンクする要素を含める必要があります。
このSCA要件は、2FAトランザクションの時点で、支払い先と一緒にトランザクションの支払い金額をユーザーに提供する必要があることを示しています。
たとえば、ユーザーが受信したSMSは、セキュリティ（認証）コードとそのコードの有効期限情報とともに、購入金額と販売者を確認します。 注意すべき点の1つは、購入金額と販売者が暗号化されていないことです。
別の方法は、SMSメッセージにセキュリティコードとともにURLを含めることです。 URLは、リンクされた暗号化されたトランザクション情報を必要とします。これは、ユーザーが知っているものと、セキュリティコード（ユーザーが所有しているもので受信）を介してアクセスできます。
Google AuthenticatorなどのサードパーティのTOTP準拠アプリによって生成された認証コードは、支払い/販売者情報から完全に分離されています。 これらのコードをトランザクションに動的にリンクする機能は、やや面倒です。
さらに、これらの無料アプリのほとんどには、トランザクションデータの動的リンクをサポートし、これらのアプリにアプリのクローン作成やジェイルブレイク、ルート検出を妨害する対策が含まれていることを確認するための適切な手段が含まれていない可能性があります。 とはいえ、準拠したモバイルアプリにこれらの対策を提供できる特殊なSDKとAPIがいくつかあります。
つまり、Google AuthenticatorなどのサードパーティのTOTP準拠アプリによって生成された認証コードは、支払い/販売者情報とは別に生成されるため、動的にリンクすることはできません。
チャネル独立性の要件では、「決済サービスプロバイダーは、強力な顧客認証の要素または認証コード自体が多目的デバイスを介して使用されるセキュリティ対策を採用して、その多目的デバイスから生じるリスクを軽減する必要があります。目的のデバイスが危険にさらされています。」
多目的デバイスは、モバイルデバイス、タブレット、またはラップトップの場合があります。 実際、銀行/支払いアプリと認証アプリが同じデバイス上にあるシナリオが存在する可能性があります。 いくつかのケースでは、それらは同じアプリの一部である可能性があります。 または、支払いアプリは帯域外認証チャネル（SMSなど）に依存することもできます。
チャネルとは、ユーザーと対話するための手段を指します。 ユーザーのオンライン支払い（または支払いアカウントアクセス）のチャネルと認証に使用されるチャネルは同じであってはなりません。 今日市場に出回っている利用可能なデバイスの組み合わせに関して、チャネルの独立性は多くの問題を引き起こします。 SMSを介した帯域外認証は広く展開されており、使いやすく、消費者の間で非常に人気があります。 ただし、セキュリティ上の問題がいくつか認識されています。
SMSなどの帯域外ソリューションに加えて、チャネルに依存せず実行可能な別の優れたソリューションは、モバイル認証アプリまたは銀行/支払い/マーチャントアプリへの別のクラウド認証ソリューションを介したプッシュメッセージングを使用して、支払い情報を次のようにすることです。だけでなく、一意のコード。
適切な対策を組み込んだ別の認証アプリは、暗号化された独立したチャネルを介して動的にリンクされた情報を受信し、これらの要件を満たすためのもう1つの可能な方法です。
この3部構成のシリーズのパート3では、RTSで概説されている要件を満たす必要があるいくつかのSCA実装オプションと、詳細情報を見つけるためのいくつかの場所について概説します。
Twitterで私をフォローすることを検討してください：@ wdudley2009