La autenticación reforzada de clientes (SCA): ¿qué es?

Captura-de-pantalla-2019-06-25-a-las-13.03.09

En esta entrada nos centraremos en el concepto, funcionamiento y cuestiones que suscitan estos dos últimos respecto de la aplicación de la autenticación reforzada de usuario.

¿Qué es la autenticación reforzada de usuario?

El próximo 14 de septiembre entrará en vigor una de las reformas más relevantes en cuanto a medidas de seguridad en los pagos comunitarios: la autenticación reforzada o «strong customer authentication» establecida en la Directiva (UE) 2015/2366 sobre servicios de pago en el mercado interior o «PSD2».

La autenticación reforzada de usuario (en adelante «SCA» en sus siglas en inglés) es el método por el que, cuando un usuario realice un pago electrónico u online, o cuando acceda a través a su información sobre pagos y movimientos, le serán solicitados unas credenciales reforzados en aras de asegurar su identidad y evitar fraudes, sobre todo los relacionados con el «phishing», que consistirán en: 

i. un código de un solo uso;

ii. una vinculación dinámica y; 

iii. elementos de autenticación.

¿En qué consiste la SCA?

El procedimiento por el cual un usuario se podrá autenticar mediante la SCA consistirá en los siguientes hitos: 

i. en primer lugar, el usuario deberá de identificarse utilizando dos de los tres elementos de autenticación, los cuales, huelga decir, serán elegidos por el proveedor de servicios de pago o el servicio al que se acceda. Los elementos puestos a disposición por la PSD2 son:

a. un elemento de conocimiento, es decir, algo que sólo el usuario pueda conocer (p.ej.: una contraseña, clave o pin)

b. un elemento de posesión, es decir, algo que sólo el usuario posea (p.ej.: un smartphone, un reloj inteligente, etc.);

c. un elemento de inherencia, es decir, una característica única del usuario o algo que éste sea (p.ej.: una huella dactilar, huella facial biométrica, etc.).

ii. en segundo lugar, una vez el usuario haya conseguido autenticarse se le solicitará un código de autenticación de un sólo uso, como el que se nos solicita en muchos casos al realizar un pago online por la aplicación de estándares de seguridad como el 3DSecure 1.0.

iii. por último, aunque esto no pueda considerarse un hito adicional en el proceso de autenticación, sino más bien un requerimiento del legislador europeo, se solicita que el código de autenticación de un sólo uso esté vinculado a los datos de la operación como el beneficiario o el importe.

Sin embargo, estos elementos de autenticación no pueden ser aplicados sin tener en cuenta unos requisitos:

i. deben ser independientes, es decir, el acceso a uno de ellos no debe comprometer al otro.

ii. cada elemento se debe haber diseñado para preservar la confidencialidad;

iii. uno de los elementos a usar debe ser no replicable y no reutilizable;

iv. y por supuesto, ninguno puede ser sustraído por Internet.

¿En qué casos aplica y cuáles no la autenticación reforzada de usuario?

Esta seguridad reforzada aplicará cuando (art. 97 PSD2): 

i. el usuario acceda su cuenta de pago en línea; 

ii. se inicie una operación de pago electrónico; 

iii. o se realice por un canal remoto cualquier acción que pueda entrañar un riesgo de fraude en el pago u otros abusos.

No obstante, Europa ha establecido una serie de excepciones siempre que se cumplan una serie de condiciones (art. 10 y ss. del Reglamento Delegado (UE) 2018/389):

i. al acceder a nuestra información financiera con máximo 90 días de antigüedad, siempre que no se divulguen datos sensibles o no se haya aplicado la SCA en los últimos 90 días; 

ii. al realizar pagos electrónicos por debajo de 50€, siempre que el importe acumulado de las anteriores operaciones no supere los 150€ o se hayan realizado más de cinco operaciones sin que la SCA sea aplicada; 

iii. cuando el usuario pague transportes o aparcamientos; 

iv. cuando el usuario realice un movimiento hacia a un beneficiario de confianza, no siendo aplicable en el caso de creación, modificación o confirmación de la lista de beneficiarios;

v. cuando se trate de operaciones frecuentes (salvo la primera vez); 

vi. al realizar un intercambio de créditos entre nuestras cuentas (de la misma entidad); 

vii. al realizar pagos online por debajo de 30€, siempre que el importe acumulado de las anteriores operaciones no supere los 100€ o se hayan realizado más de cinco operaciones sin que la SCA sea aplicada; 

viii. cuando la operación remota de pago esté considerada como de riesgo bajo.

Cuestiones a tener en cuenta

Analizado de forma superficial el funcionamiento y los casos de aplicación y las excepciones; conviene detallar ciertas cuestiones que desde el punto de vista jurídico y de mercado son interesantes:

i. nos encontramos con una serie de medidas que en pro de la seguridad y la confidencialidad de los usuarios podrían hacer cierto daño en la conversión de las potenciales compras en compras definitivas, pues el añadir requisitos puede suponer que el usuario abandone el proceso de compra antes de cerrarlo, y este es precisamente uno de los miedos de los e-commerce.

ii. por otro lado, podemos advertir que se han detallado ciertos requisitos de independencia (artículo 9 del Reglamento Delegado (UE) 2018/389) para los elementos de autenticación que pueden ser adaptados a dispositivos polivalentes. De esta forma, si contamos con uno de estos dispositivos, para asegurar la independencia deberá haber entornos de ejecución separados, mecanismos que impidan la modificación de los programas, y mecanismos que mitiguen las consecuencias de las modificaciones; a lo que cabe preguntarse ¿Si disponemos de un smartphone con lector de huella dactilar/reconocimiento facial por el que accedemos al OTP, deberíamos ceder nuestra información biométrica a los proveedores de servicios? ¿Cómo se articularán este tipo de medidas sin incidir en la privacidad de los usuarios?

iii. asimismo, resulta interesante los requisitos de vinculación dinámica a los que se refiere el artículo 5 del Reglamento (UE) 2018/389, y por los que los códigos de autenticación de un solo uso (OTP) han de estar vinculados con la cantidad de unidades monetarias a transferir o abonar y el beneficiario, pero asegurando su integridad, autenticidad y confidencialidad. En este sentido, crea cierta expectación desde el punto de la vista de la privacidad el saber cómo se puede generar un OTP con detalles sobre la operación, supuestamente anonimizados (práctica más que complicada si consultamos la reciente guía de la AEPD sobre K-anonimización) de que no sea fácilmente vinculable a una persona o cliente, y no permita la identificación de las partes en una operación, si previamente se consigue acceso a las bases de datos.

Pablo Viedma

Tech & Privacy Lawyer