银行业挑战加起来：PSD2 意味着新的数据共享规则

毫无疑问，你们中的许多人都听说过名为 PSD2（支付服务指令的缩写）的欧盟欧洲银行管理局（或 EBA）指令。 这些指南最初于 2015 年底发布。到 2018 年 1 月，所有成员国都必须执行这些规定。

如果银行业还没有考虑到一个非常数字化的未来，他们将面临许多挑战。

了解欧盟 PSD2 的强客户身份验证

PSD2 的主要用途包括：

1. 为在线商家等各种参与者开辟新的市场机会，同时为所有主要利益相关者创造公平的竞争环境
2. 提供消费者透明度和消费者选择
3. 为在线支付引入新的、更强大的安全实践

PSD2 一般有许多指导方针； 但是，可以从 MEF（移动生态系统论坛）下载更好的 PSD2 指南之一。

强大的客户认证

PSD2 法规的关键要素之一是强客户身份验证（或 SCA）的概念。 EBA 指出：“多亏了 PSD2，消费者在进行电子支付或交易（例如使用网上银行或在线购买）时将得到更好的保护。

监管技术标准 (RTS) 使强大的客户身份验证 (SCA) 成为访问个人支付账户以及在线支付的基础。” 简而言之，SCA 至少需要双因素身份验证 (2FA)。

双因素身份验证意味着用户必须通过三个独立的两个元素来“证明”他们的身份：

1. 他们知道的东西（PIN 码或密码）
2. 他们拥有的东西（移动设备、卡）
3. 它们是什么（指纹、面部扫描：例如生物识别）

EBA 指出 SCA 在整个欧盟普遍使用； 但是，对于信用卡支付或直接银行转账等在线支付交易，情况并非总是如此。 SCA 适用于欧盟国家比利时、荷兰和瑞典）； 然而，根据欧盟委员会的出色新闻稿，在其他欧盟国家，SCA 仅在自愿的基础上应用。

虽然欧盟成员国本应在 2018 年 1 月之前实施 PSD2，但 SCA 将在 EBA 监管技术标准 (RTS) 生效之日后 18 个月后成为强制性标准（预计将于今年晚些时候生效） . 因此，从本质上讲，我们正在关注 2019 年中后期（一些文件引用的 2019 年 9 月就是这样一个日期）。 这将使所有利益相关者有足够的时间将 SCA 和其他安全要求纳入他们的系统和工作流程。

2FA 用于 SCA

鉴于 SCA 时间表，2018 年是企业开始实施 2FA 解决方案以解决所需的更高安全性的最佳时机。

国际律师事务所 Taylor Wessing 在他们的论文： PSD2 下的强客户身份验证中指出，“EBA 与咨询文件的大多数受访者一致认为，为了确保技术中立性并允许开发用户友好型、可访问和创新的支付方式，它不应该进一步定义身份验证元素。” 这意味着 EBA 没有指定 2FA 的实施方式。 有多种方案，包括通过移动渠道（如 SMS 或推送通知或更传统的电子邮件渠道）传递令牌，以及 TOTP 软令牌解决方案等。

综上所述，我们应该指出，与任何好的 2FA 实施方案一样，存在一些限制和具体规定，需要仔细考虑。

验证码

RTS 注意到，验证码的生成满足以下条件：

1. 不能从认证代码的披露中获得有关知识、拥有和继承的信息
2. 不可能根据先前生成的任何其他验证码的知识生成新的验证码
3. 验证码不可伪造

此外，RTS 规定，在代码的有效时间内不应尝试超过 5 次失败的身份验证尝试，并且付款人或用户在通过身份验证以在线访问其支付账户后不进行任何活动的最长时间不得超过 5 分钟.

交易的动态链接

RTS 表明电子远程交易——本质上是通过互联网进行的支付（无论是在笔记本电脑或移动设备等桌面设备上）必须包含“将交易动态链接到特定金额和特定收款人”的元素。 RTS 认为这是 SCA 的一种附加形式。

对于此 SCA 要求，应在 2FA 交易时将支付交易的金额以及收款人（或商户）提供给用户。 如果金额或收款人有任何变化，则应生成另一个验证码（例如，将该代码“动态链接”到新的收款人和/或支付金额）。 一条包含所有必需信息的 SMS 消息可能如右图所示：10 分钟安全码、商户（或收款人）名称和交易金额。

有趣的是，由第三方 TOTP 兼容应用程序（如 Google Authenticator）生成的验证码与支付/商家信息完全分开生成，因此无法动态链接。

渠道独立

这个要求有点棘手。 RTS 指出，“支付服务提供商应采取安全措施，在通过多用途设备使用强客户身份验证的任何元素或身份验证代码本身时，以减轻该多用途设备可能带来的风险受到损害。” 多功能设备可以是移动设备或平板电脑，甚至是笔记本电脑。

如果用户在笔记本电脑上并被要求进行付款，那么该商家可以向用户的移动设备发送一条短信，其中包含收款人（例如商家）以及他们将要支付的金额以及身份验证短信正文中的代码。

在另一个示例中，如果用户正在使用移动设备与商家交互并发起支付，那么这种渠道独立性不会明确禁止 SMS 或任何移动特定的交付渠道。 在这里，这是一条细线。 在许多情况下，用户拥有的唯一设备是多用途设备，例如手机。 但是，通道独立性只是——同一设备上的独立通道——带有验证码的短信与手机是不同的通道（实际上，它是一个带外通道，通过手机号码到达）用户与商家互动的应用程序或网络浏览器。 相同的渠道独立性将适用于使用移动应用程序生成符合 TOTP 的代码（例如 Google Authenticator），但如前所述，TOTP 投诉代码无法动态链接交易。

相反，如果用户使用移动应用程序访问商家，则无法向同一个应用程序（使用验证码）推送通知，因为它们是同一个渠道。

有些人会说基于 SMS 的 2FA 非常不安全，在某些情况下，这可能是真的。 是的，在一些孤立的情况下，攻击者设法通过一个运营商的 SS7 访问 2FA SMS 消息； 但是，其中许多漏洞已被关闭。 此外，如何生成验证码并将其提供给用户以及消息服务提供商如何提供此类验证码也非常重要。

在多用途设备盛行的情况下（如今，这些设备已经并将继续成为最普遍的设备），移动运营商提供的消息传递通道应该继续成为 2FA 令牌的可行带外通道。

对于更详细的分析，我发现了 Frederik Mennes 的一篇信息丰富的博客文章，其中提供了更多关于哪些类型的场景（尤其是多用途设备）应该符合 PSD2 SCA 的详细信息。

PSD2 SCA 不应掉以轻心，但许多已经实施的 2FA 解决方案应该可以工作； 但是，我们也知道许多在线商家尚未提供符合 PSD2 SCA 的解决方案。 在撰写本文时，仍有充足的时间将 SCA 纳入支付工作流程。

SAP Authentication 365 是一种解决方案，它提供基于 API 的云解决方案，使企业能够实施符合 PSD2 的 SCA。 SAP Authentication 365 移动服务是一种端到端服务，可让您快速安全地实施多通道双因素身份验证 (2FA) 服务，并为您的数字业务量身定制身份验证。

它通过 SMS、电子邮件、推送通知或 TOTP 软令牌启用身份验证，有助于保护企业客户的身份和数据。 SAP 的 REST API 简化了验证或身份验证代码的生成和身份验证，并提供了实现符合 PSD2 的 SCA 策略的灵活性和功能。