PSD2: autenticación sólida de clientes en la UE

Esta es la segunda de una serie de publicaciones en tres partes que detallan PSD2: autenticación sólida de clientes en la UE (SCA).

En la primera entrega de esta serie de tres partes, presentamos la directiva de la Autoridad Bancaria Europea (o EBA) de la Unión Europea llamada PSD2 (abreviatura de La Segunda Directiva de Servicios de Pago) y describimos algunos de los principios rectores de la autenticación sólida de clientes (o SCA). .

Refiriéndose a SCA, la EBA señala: “Gracias a PSD2, los consumidores estarán mejor protegidos cuando realicen pagos o transacciones electrónicas (como usar su banca en línea o comprar en línea). Como se señaló en la Parte 1, el Estándar técnico regulatorio (RTS) hace que la autenticación sólida del cliente (SCA) sea la base para acceder a la cuenta de pago de uno, así como para realizar pagos en línea".

En esta publicación, exploraremos las limitaciones y los reguladores de SCA que los implementadores deben considerar. Primero, veamos los códigos de autenticación que se generan. Recuerde, esto es esencialmente autenticación de dos factores o 2FA.

El RTS describe las siguientes condiciones para los códigos de autenticación:

• No se puede derivar información sobre el conocimiento, la posesión y la herencia de la divulgación del código de autenticación. Esto significa que si conoce el código de autenticación, no hay forma de obtener ningún otro elemento de conocimiento (por ejemplo, una identificación de usuario), lo que el usuario tiene en su poder (por ejemplo, un teléfono móvil, lo que significa que no puede obtener el número de teléfono móvil) o herencia – aspectos sobre los propios usuarios, como la biometría.
• No es posible generar un nuevo código de autenticación basado en el conocimiento de cualquier otro código de autenticación generado previamente . Para esta condición, dado cualquier código de autenticación, no hay forma de generar un nuevo código de autenticación haciendo referencia a uno o varios códigos de autenticación anteriores.
• El código de autenticación no se puede falsificar . El implementador debe crear códigos de autenticación para que los códigos falsificados o falsificados no puedan validarse con éxito.
• No se deben intentar más de 5 intentos de autenticación fallidos dentro del tiempo de vida del código. Cada código generado tendrá un tiempo de caducidad o “tiempo de vida”. Este temporizador comienza inmediatamente después de que se generó el código e incluye el tiempo de entrega. Una buena regla general es que el código debe caducar en 15 minutos o menos. Algunas organizaciones toman esto a 30 minutos o 1 hora, pero esto puede ser demasiado tiempo. Si el usuario intenta autenticarse con el código y falla 5 veces, entonces se debe enviar un nuevo código. Esto evita cualquier tipo de intento de fuerza bruta para descifrar el código.
• El tiempo máximo sin actividad del pagador o usuario después de autenticarse para acceder a su cuenta de pago en línea no excederá de 5 minutos . Este es un temporizador de inactividad estándar y, aunque está separado del código de autenticación, es un temporizador que se inicia una vez que el usuario se autentica correctamente y no realiza ninguna actividad.

Todas estas son condiciones relativamente estándar para la generación/validación del código de autenticación utilizado en situaciones 2FA.

Ahora echemos un vistazo al requisito de RTS llamado Vinculación dinámica de las transacciones. Las transacciones remotas electrónicas (por ejemplo, realizadas a través de Internet, independientemente de si el dispositivo era una computadora de escritorio o un dispositivo móvil) deben incluir elementos que “vinculen dinámicamente la transacción con el monto específico (del pago) y el beneficiario específico.

Este requisito de SCA indica que el monto del pago de la transacción junto con el destinatario del pago debe devolverse al usuario en el momento de la transacción 2FA.

Por ejemplo, un SMS recibido por el usuario verificaría el monto de la compra y el comerciante, junto con el código de seguridad (autenticación) y la información de vencimiento de ese código. Una cosa a tener en cuenta es que el monto de la compra y el comerciante no están encriptados.

Una alternativa sería incluir una URL junto con el código de seguridad en el mensaje SMS. A la URL le gustaría la información de transacción encriptada y vinculada, accesible a través de algo que el usuario conoce, así como el código de seguridad (recibido en algo que el usuario posee).

Los códigos de autenticación generados por aplicaciones compatibles con TOTP de terceros, como Google Authenticator y muchas otras, están completamente separados de la información de pago/comerciante. La capacidad de vincular dinámicamente estos códigos a la transacción es algo problemática.

Además, es posible que la mayoría de estas aplicaciones gratuitas no contengan las medidas adecuadas para respaldar la vinculación dinámica de datos de transacciones y para garantizar que estas aplicaciones contengan contramedidas para interrumpir la clonación de aplicaciones, así como la fuga y la detección de raíz. Dicho esto, existen algunos SDK y API especializados que pueden proporcionar estas contramedidas a las aplicaciones móviles compatibles.

Esto significa que un código de autenticación generado por una aplicación compatible con TOTP de terceros, como Google Authenticator, se genera por separado de la información de pago/comerciante y, por lo tanto, no se puede vincular dinámicamente.

El requisito de independencia del canal establece que “los proveedores de servicios de pago adoptarán medidas de seguridad, cuando cualquiera de los elementos de la autenticación fuerte del cliente o el propio código de autenticación se utilice a través de un dispositivo multipropósito, para mitigar el riesgo que resultaría de esa autenticación múltiple. el dispositivo de propósito está comprometido”.

El dispositivo polivalente puede ser un dispositivo móvil, una tableta o un ordenador portátil. De hecho, es probable que haya escenarios en los que la aplicación bancaria/de pago y la aplicación de autenticación estén en el mismo dispositivo. En algunos casos, podrían ser parte de la misma aplicación. Alternativamente, la aplicación de pago podría depender de un canal de autenticación fuera de banda (como SMS).

Los canales se refieren a los medios en los que interactuar con el usuario. El canal para el pago en línea del usuario (o acceso a la cuenta de pago) y el canal utilizado para la autenticación no deben ser el mismo. En términos de las combinaciones de dispositivos disponibles que se encuentran en el mercado hoy en día, la independencia del canal plantea una serie de problemas. La autenticación fuera de banda a través de SMS está ampliamente implementada, es fácil de usar y es bastante popular entre los consumidores; sin embargo, tiene algunos problemas de seguridad percibidos.

Además de las soluciones fuera de banda como SMS, otra buena solución viable e independiente del canal sería usar un mensaje push a través de una solución de autenticación en la nube separada para una aplicación de autenticación móvil o incluso la aplicación bancaria/pago/comerciante con la información de pago como así como un código único.

Una aplicación de autenticación separada que incorpore las contramedidas apropiadas, que reciba información vinculada dinámicamente a través de un canal independiente encriptado, es otro método posible para satisfacer estos requisitos.

En la tercera parte de esta serie de tres partes , describiremos algunas opciones de implementación de SCA que deberían satisfacer los requisitos descritos en las RTS, así como algunos lugares para encontrar más información.

Considere seguirme en Twitter: @wdudley2009

Conozca los efectos que la actual crisis de salud podría tener en la estrategia comercial, la transformación digital y el futuro del comercio electrónico AQUÍ.