La autenticación fuerte de cliente de conformidad con la PSD2: el bueno, el malo y el feo

Frederik Mennes, 12 de Septiembre de 2019

En unos días, el 14 de septiembre de 2019, los requisitos de autenticación sólida de cliente (SCA) tan esperados bajo PSD2 finalmente entrarán en vigencia. Publicado hace aproximadamente 18 meses por la Comisión Europea en los Estándares Técnicos Regulatorios (RTS) sobre Autenticación Sólida de Clientes y Comunicación Común y Segura, estos requisitos afectarán la forma en que los consumidores en Europa acceden a sus aplicaciones de banca por Internet, pagan por compras de comercio electrónico y utilizar nuevos servicios financieros proporcionados por terceros proveedores (TPP) a través de Open Banking.

En este artículo, analizamos SCA en PSD2 y evaluamos qué salió bien y qué se requiere para una implementación exitosa de SCA en Europa.

1) Lo bueno

PSD2 está aumentando el nivel de seguridad para la autenticación de los servicios financieros en toda Europa y está armonizando la solidez de los procesos de autenticación para las aplicaciones financieras.Debido a PSD2, las instituciones financieras han ido eliminando los métodos de autenticación débiles. Algunos ejemplos son soluciones basadas únicamente en combinaciones de nombre de usuario / contraseña, y soluciones basadas en listas impresas de códigos de autenticación, como listas TAN y tarjetas de matriz. Como confirma el Dictamen de la Autoridad Bancaria Europea (EBA) de 21 de junio, estas soluciones no cumplen los requisitos de la SCA.

PSD2 garantiza que los conceptos de autenticación avanzada, como la vinculación dinámica, la vinculación de dispositivos para aplicaciones móviles, el blindaje de aplicaciones móviles y el análisis de riesgos de transacciones se conviertan en herramientas de seguridad estándar en los servicios financieros. En este sentido, PSD2 va mucho más allá de la EBA Directrices finales sobre la seguridad de los pagos por Internet , que entró en vigor el 1 de agosto de 2015 y será reemplazado por PSD2 el 14 de septiembre.

PSD2 también está acelerando la adopción de métodos de autenticación adaptativos, que ajustan la forma en que el usuario se autentica al riesgo de lo que el usuario quiere hacer. Como tal, PSD2 permite lograr un equilibrio específico del usuario entre comodidad y seguridad. Este enfoque se incluyó en el RTS gracias a la apertura de la EBA y la estrecha colaboración con los actores de la industria durante la redacción del RTS.

2) lo malo

PSD2 asigna la responsabilidad de proteger el acceso a las cuentas bancarias con los bancos, también conocidos como proveedores de servicios de pago de servicios de cuentas (ASPSP). Dado que los bancos son propietarios de las cuentas bancarias, esto parece tener sentido a primera vista.

Sin embargo, al mirar más de cerca, queda claro que este enfoque crea una complejidad significativa en el contexto de la Banca Abierta, de la siguiente manera:

  • En primer lugar, los usuarios de las aplicaciones TPP deberán autenticarse dos veces: una vez para acceder a la aplicación TPP y una segunda vez para usar una determinada cuenta bancaria a través de la aplicación TPP.
  • Además, el método de autenticación y el flujo de una determinada cuenta bancaria dependen del banco. Por ejemplo, el banco A podría implementar la autenticación mediante un lector de tarjetas y un enfoque de "redireccionamiento", mientras que el banco B podría usar una aplicación móvil mediante el enfoque "desacoplado". Por lo tanto, la experiencia del usuario dentro de la aplicación TPP dependerá del banco.

Como consecuencia, la experiencia de autenticación general para el usuario promedio de TPP promete ser complicada.

Sin embargo, PSD2 en sí no tiene la culpa de esto. El problema es la consecuencia de un problema mayor que trasciende la PSD2, a saber, la ausencia de un sistema de identidad digital paneuropeo basado en identidades verificadas y confiables. La inspiración para tales sistemas ya se puede encontrar en varios países, como Suecia (identificación bancaria) e India (Aadhaar). El desafío es construir tal sistema a nivel europeo. Dicho sistema es clave para el futuro de Open Banking.Artículo reciente de Citi proporciona más inspiración para esto.

3) El feo

Los requisitos de SCA de PSD2 están pensados para ser preparados para el futuro e independientes de la tecnología. Proporcionan cierto margen de maniobra a los proveedores de servicios de pago (PSP), lo que significa que los PSP pueden decidir cómo cumplir mejor con un determinado requisito.Sin embargo, esto puede dejar a los PSP, que deben cumplir con los requisitos, en la oscuridad. Algunos ejemplos:

  • Uso de SMS para enlaces dinámicos . La EBA ha aclarado en su dictamen del 21 de junio que los SMS pueden considerarse un elemento de posesión válido. Más específicamente, la tarjeta SIM en el dispositivo móvil que recibe el SMS es un elemento de posesión válido. Esto implica que las contraseñas de un solo uso (OTP) entregadas a través de SMS se pueden utilizar para construir un mecanismo de autenticación sólido cuando se combinan con un segundo factor (por ejemplo, una contraseña o PIN). Sin embargo, el dictamen no aclara si los SMS se pueden utilizar para enlaces dinámicos. De hecho, el requisito de vinculación dinámica en el artículo 5 de la RTS estipula que la confidencialidad e integridad de la información de pago (por ejemplo, número de cuenta bancaria, cantidad de dinero) debe protegerse durante el proceso de autenticación. Dado que el contenido de un SMS normalmente no está protegido, parece SMS no cumple con los requisitos de enlace dinámico .
  • Creación de un entorno de ejecución seguro para aplicaciones móviles . El RTS establece que los PSP deben utilizar entornos de ejecución seguros para proteger las aplicaciones móviles. Sin embargo, el RTS final no define qué un entorno de ejecución seguro realmente lo es, o cómo podría implementarse. Dado el estado actual de la seguridad de las aplicaciones móviles, el mejor enfoque para cumplir con este requisito probablemente consista en utilizar tecnología de protección de aplicaciones , protegiendo la aplicación contra amenazas como superposiciones, inyección de código y registro de teclas.

Finalmente, el cronograma para la aplicación de los requisitos de la SCA de PSD2 ha comenzado a cambiar en los últimos meses. Originalmente, los requisitos de la SCA para las aplicaciones de comercio electrónico y banca por Internet serían aplicables el 14 de septiembre de 2019. En la misma fecha, entraría en vigor el requisito de que los bancos proporcionen una interfaz de comunicación para Open Banking. Sin embargo, desde que la ABE publicó su dictamen el 21 de junio, los plazos se han vuelto más fragmentados. En el momento de redactar este documento los plazos son los siguientes:

  • Fecha límite para que los bancos implementen SCA para la banca por Internet: 14 de septiembre de 2019, excepto en el Reino Unido, donde la fecha límite es ahora el 14 de marzo de 2020
  • Fecha límite para implementar SCA para pagos con tarjeta para comercio electrónico: se permiten retrasos específicos del país
  • Fecha límite para que los bancos ofrezcan interfaces de banca abierta: 14 de septiembre de 2019

Como consecuencia, diferentes PSP pueden tener diferentes plazos para cumplir con los requisitos de la SCA, y esto podría afectar los pagos cuando estén involucrados varios PSP. Por ejemplo, si se realiza un pago con tarjeta entre un emisor de tarjetas que cumple el 14 de septiembre de 2019 y un adquirente que ha recibido una extensión de, digamos, 6 meses, entonces el adquirente podría enviar una solicitud de pago sin SCA al emisor, pero el El emisor rechazará el pago porque requiere SCA. Como consecuencia, los pagos podrían rechazarse aunque tanto el emisor como el adquirente actúen correctamente. Esto claramente plantea la necesidad de que las Autoridades Competentes (CA) otorguen extensiones de manera coordinada. La ABE debería desempeñar el papel de coordinadora entre las distintas AC aquí.

En la épica película de Sergio Leone de 1966, el Bueno se lleva el oro, el Malo muere y el Feo se salva por la misericordia del Bueno. Esperemos que el guión de la película se aplique también a PSD2.

PSD2: ¿Qué soluciones de autenticación fuerte y transacciones cumplen?
DOCUMENTO TÉCNICO

PSD2: ¿Qué soluciones de autenticación fuerte y transacciones cumplen?

Descubra los requisitos más importantes del RTS final y qué soluciones de autenticación tienen más probabilidades de cumplir los requisitos.

Descargar ahora

Se realiza un análisis más profundo de PSD2 y sus requisitos de autenticación sólida de clientes. disponible aquí .

Frederik dirige el Centro de Competencia de Seguridad de OneSpan, donde es responsable de los aspectos de seguridad de los productos y la infraestructura de OneSpan. Tiene un profundo conocimiento de las tecnologías de autenticación, gestión de identidades, normativa y seguridad para aplicaciones en la nube y móviles.