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

La autenticación reforzada de cliente que exige PSD2 son dos factores de categorías distintas para entrar en una cuenta de pago o para ordenar un pago electrónico. Obliga al proveedor de servicios de pago, no al comercio.

PSD2 es la Directiva (UE) 2015/2366 y en España la aplica el artículo 49 del Real Decreto-ley 19/2018. Ese artículo dice cuándo hay que pedirla: al acceder a una cuenta de pago en línea, al iniciar un pago electrónico y en cualquier acción por canal remoto que pueda entrañar riesgo de fraude. Lo demás, que es casi todo el trabajo, está en las normas técnicas.

¿A quién obliga PSD2?

Los sujetos obligados son los proveedores de servicios de pago: bancos, entidades de dinero electrónico, entidades de pago y las pasarelas que operan como tales. Un comercio online no está en esa lista. Lo que pasa en la práctica es otra cosa. La pasarela le traslada la exigencia por contrato, el comercio monta el flujo de compra y acaba respondiendo de su parte aunque la norma no le nombre.

La frontera importa el día que algo falla. Si un pago se aprueba sin segundo factor porque el checkout mandó un parámetro que el proveedor aceptó, el fallo está en tu lado del cable. Es el reparto que discutimos en casi todas las reuniones de alcance. Si además aceptas tarjeta, PCI DSS para comercios te llega por otra vía y con otro alcance.

Qué cuenta como autenticación reforzada de cliente

Cuentan dos elementos, y de categorías distintas. Repetir dos contraseñas no sirve: las dos son conocimiento. Estas son las tres categorías que reconoce la norma.

• › 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.

El artículo 9 del Reglamento Delegado (UE) 2018/389 pide además que los elementos sean independientes: que comprometer uno no arrastre la fiabilidad de los otros. El móvil es el caso difícil. Ahí ocurre casi todo, y la norma admite el segundo factor en el mismo dispositivo siempre que haya entornos de ejecución separados, comprobación de que el aparato no está manipulado y medidas para cuando ya lo está. Con eso se cae una idea muy extendida: que un código por SMS al mismo teléfono desde el que se paga cumple sin más.

Las exenciones, con sus umbrales

El Reglamento Delegado (UE) 2018/389, aplicable desde el 14 de septiembre de 2019, permite no pedir autenticación reforzada en varios casos tasados. Cada uno trae su artículo, su umbral en euros y su contador. El contador se reinicia al aplicar el segundo factor.

La tabla del anexo es la parte que casi nadie mira, y es la que decide el importe. Para eximir hasta 500 € por análisis de riesgo, la tasa de fraude del proveedor en pagos con tarjeta remotos tiene que estar en el 0,01 % o por debajo. Para 250 €, en el 0,06 %. Para 100 €, en el 0,13 %. En transferencias los números aprietan más todavía. Una exención así se sostiene mientras la tasa aguante, y se cae sola cuando el fraude sube.

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

El artículo 5 del Reglamento Delegado (UE) 2018/389 exige que el código de autenticación quede atado al importe y al beneficiario concretos de esa operación, y que cualquier cambio en uno de los dos lo invalide. Si el código sirve para otro pago, la vinculación no existe.

Este fallo no se ve usando la aplicación con normalidad. Aparece cuando alguien intercepta la petición, cambia el destinatario y el código sigue valiendo. Se arregla en el servidor. El hallazgo cabe en una página del informe.

Lo que casi siempre está mal entendido

Al auditar flujos de pago hay creencias que se repiten en casi todas las integraciones. Estas son las que más nos encontramos, y todas se corrigen leyendo el artículo que las regula.

• › «Los cobros recurrentes están exentos». El artículo 14 exime la serie solo si el importe y el beneficiario son los mismos. Una suscripción que factura por consumo cambia de importe cada mes, así que cada cobro es una operación nueva.
• › «Activamos el análisis de riesgo y listo». La exención del artículo 18 la sostiene la tasa de fraude del proveedor de servicios de pago, no la del comercio, y el importe máximo baja en cuanto esa tasa sube.
• › «Nos metemos en la lista de beneficiarios de confianza». Esa lista la crea el pagador desde su banco, y crearla o modificarla exige autenticación reforzada (artículo 13). Un comercio no se añade solo.

Cómo atacamos un flujo de pago para saber si aguanta

Una implantación de PSD2 se comprueba atacando el flujo entero, con el alcance y las credenciales acordados antes de empezar. Auditamos la API que orquesta el pago, el checkout web y, si existe, la aplicación móvil. Intentamos saltarnos el segundo factor, reutilizar un código en otra operación y forzar una exención que no corresponde. Leer el código no vale para esto.

Lo que sale casi siempre son fallos de lógica, no de criptografía, y por eso no los ve un escáner:

• › Parámetros de importe que salen del navegador y el servidor acepta sin validar, con lo que la cifra se baja hasta caer por debajo de los 30 €.
• › Contadores acumulados que se reinician al cerrar sesión, al cambiar de dispositivo o al pasar por el flujo de invitado.
• › Códigos que siguen valiendo minutos después, o en una segunda operación con otro beneficiario.
• › Caminos alternativos, como la recuperación de contraseña o el alta de un método de pago, que llegan al mismo sitio sin pasar por el segundo factor.

En Pentesting Team esto entra en un pentesting de APIs o en uno de aplicaciones web, según dónde viva la lógica que decide si se pide el segundo factor. Se hace a mano. Antes de empezar entregamos un plan de auditoría por escrito con las fechas, las pruebas previstas y el equipo. El proveedor que te integró la pasarela puede revisar su configuración. Lo que no va a hacer es intentar romper su propia integración, porque su incentivo es que salga limpia y el nuestro es encontrar lo que falla.

Qué cuesta comprobarlo y qué no hace falta pagar

Un pentesting de APIs parte de 760 € y uno de aplicación web, de 1.140 €. Una auditoría de aplicación web lleva de una a tres semanas, según el número de flujos y de roles de usuario. Se entrega el informe con cada hallazgo, su criticidad, su evidencia y los pasos para reproducirlo, la presentación de resultados para dirección y un retest a los seis meses.

Lo que no merece la pena pagar es una auditoría del motor de autenticación de tu proveedor. Ese componente lo certifica quien lo vende y tú no lo puedes cambiar. El dinero rinde en la lógica que decide cuándo se pide el segundo factor, que sí es tuya, y en los caminos que la rodean. Si solo da para una cosa, empieza por ahí.

El lunes por la mañana, pide a quien mantiene el checkout la lista de condiciones con las que hoy se salta el segundo factor, con el artículo del Reglamento Delegado al lado de cada una. Si esa lista no existe, o nadie sabe quién la escribió, ya tienes el alcance de la primera auditoría. Lo que debe traer el informe está en qué debe incluir un informe de pentesting.