PSD2: qué es la autenticación reforzada y a quién obliga

PSD2 es la Directiva (UE) 2015/2366, que en España se transpuso con el Real Decreto-ley 19/2018. Su exigencia más visible es la autenticación reforzada de cliente: para entrar en una cuenta de pago o para ordenar una operación electrónica hacen falta dos factores independientes.

¿A quién obliga PSD2?

Obliga a los proveedores de servicios de pago: bancos, entidades de dinero electrónico, pasarelas y agregadores. Un comercio no es sujeto obligado. Lo que sí ocurre es que su pasarela le traslada la exigencia, así que quien vende online acaba integrando la autenticación reforzada aunque la norma no le nombre.

Qué cuenta como autenticación reforzada

Dos factores, y de categorías distintas. Repetir dos contraseñas no vale, porque las dos son conocimiento. Las tres categorías son:

• › Conocimiento: algo que el usuario sabe, como una contraseña o un PIN.
• › Posesión: algo que tiene, como el móvil registrado o una tarjeta.
• › Inherencia: algo que es, como la huella o el reconocimiento facial.

Los factores tienen que ser independientes. Si el segundo factor llega por SMS al mismo dispositivo donde se está haciendo el pago, y ese dispositivo está comprometido, el atacante tiene los dos. La norma pide además vincular el código a la cantidad y al beneficiario, para que no se pueda reutilizar en otra operación.

Las exenciones son la mitad del trabajo

PSD2 permite saltarse la autenticación reforzada en varios casos: importes bajos, pagos recurrentes con el mismo beneficiario, beneficiarios de confianza y operaciones que el análisis de riesgo clasifica como seguras. Cada exención tiene sus límites y sus contadores.

Ahí es donde aparecen los fallos que encontramos. No en el algoritmo de autenticación, que suele venir del proveedor, sino en la lógica que decide cuándo pedirla. Un contador que se reinicia donde no debe o un parámetro de importe que viaja del navegador al servidor sin validar convierten la exención en una puerta.

Cómo se comprueba que funciona

Se comprueba atacándolo, no leyendo el código. Auditamos el flujo de pago entero: la API que lo orquesta, la web y, si existe, la aplicación móvil. Buscamos saltarnos el segundo factor, reutilizar un código en otra operación y forzar una exención que no corresponde. Lo que sale entra en el informe con los pasos para reproducirlo, y a los seis meses volvemos a probarlo.

Las exenciones, una a una

Vinculación dinámica: el requisito que más se implanta mal

En los pagos electrónicos, el código de autenticación tiene que estar vinculado al importe y al beneficiario concretos de esa operación. Si el código sirve para cualquier pago, la vinculación no existe. Es un fallo que no se ve usando la aplicación con normalidad y que aparece en cuanto alguien intercepta la petición y cambia el destinatario.

Qué encontramos con más frecuencia

• › Parámetros de importe que viajan desde el cliente y se aceptan sin validar en servidor, lo que permite bajar la cifra hasta caer en la exención de importe reducido.
• › Contadores de operaciones acumuladas que se reinician al cerrar sesión.
• › Códigos válidos durante más tiempo del necesario, o reutilizables en una segunda operación.
• › Flujos alternativos, como la recuperación de contraseña, que permiten llegar al mismo sitio sin pasar por el segundo factor.

Los cuatro son fallos de lógica, no de criptografía, y por eso no los detecta un escáner. Se encuentran probando el flujo a mano, que es lo que hacemos en una auditoría de API o de aplicación web.