Autenticación reforzada en el marco de la directiva de pagos PSD2

Cisco_ASA_821_login_request_sms_turing_OTP_and_Password

La directiva revisada de servicios de pago (PSD2) de la comision europea establece el requisito de Autenticacion Reforzada (Strong Authentication) como uno de los pilares esenciales para garantizar la seguridad de los pagos minoristas por Internet. Esta directiva es un paso más en el camino hacia un mercado digital europeo único y favorece el crecimiento de la economía, a los consumidores y empresas, a la vez que se orienta a reducir los niveles de fraude en las transacciones online.

Sin embargo, la directiva tiene algunos puntos ambigüos que deberán ser aclarados por la EBA (Autoridad Bancaria Europea) en un futuro estándar técnico. En este artículo vamos a hacer un repaso al requisito de Autenticación Reforzada, haciendo especial énfasis en aquellos puntos que, a nuestro juicio, necesitan una mayor clarificación por parte de la EBA.

La PSD2 sigue el planteamiento adoptado por la anterior Directiva 2007/64/CE que abarcaba los siguientes servicios de pago por Internet:

  • Realización de operaciones de pago con tarjeta, incluidas las tarjetas virtuales, a través de Internet, así como el registro de los datos relativos a la tarjeta de pago para su empleo en “soluciones de tipo monedero”;
  • Transferencias realizadas a través de Internet:
  • Emisión y modificación de mandatos electrónicos relativos a adeudos domiciliados;
  • Transferencias de saldos entre dos cuentas de dinero electrónico a traves de Internet.

El requisito de Autenticación Reforzada

La PSD2 requiere que los procesadores de servicios de pagos por Internet, establezcan mecanismos de Autenticación Reforzada y medidas de seguridad para proteger las credenciales de seguridad de los usuarios cuando éstos:

  • Acceden a su cuenta de pago online
  • Inician una transacción de pago electrónico, o
  • Llevan a cabo, a través de canales remotos, cualquier acción que pueda implicar un riesgo de pago fraudulento u otros abusos.

Además, en relación con las transacciones de pago online, la Autenticación Reforzada debe inlcuir elementos que asocien dinámicamente la transacción a la cantidad específica y al beneficiario de la misma; es decir, uno de los elementos de la autenticación debe ser calculado dinámicamente y en su cálculo deben usarse estos datos específicos de la transacción; de esta manera el código de autenticación así generado no podría ser usado en otra operación distinta.

En mi oponión, el requisito está definido de una manera tan general, que implicaría de hecho que se use la Autenticación Reforzada en todas y cada una de las acciones en un servicio web de pagos, inlcuido el acceso inicial. Esto podría tener un alto impacto en coste y usabilidad pero, afortunadamente, la PSD2 contempla la posibilidad de excepciones al requisito basadas en el riesgo asociado. Sobre estas excepciones hablaremos más adelante.

iphone-otp

¿En qué consiste?

La Autenticación Reforzada se basa en el uso combinado de dos o más elementos del tipo:

  • Algo que solamente el usuario conoce (CONOCIMIENTO); por ejemplo, una contraseña.
  • Algo que solamente el usuario posee (POSESIÓN); por ejemplo, un token, una tarjeta, un teléfono móvil
  • Algo que el usuario es (INHERENCIA); por ejemplo, un rasgo biométrico como la huella digital, el iris..

Además, estos elementos deben ser:

  • Independientes, esto es, el compromiso de uno de los elementos no implica el compromiso de los otros; por ejemplo, aunque un hacker pueda robar mediante un keylogger una contraseña (algo que el usuario sabe), esto no implica que el delincuente tenga acceso a otros elementos físicos como el token o el teléfono móvil.
  • Diseñado para preservar la confidencialidad de los datos de autenticación.
  • Al menos uno de los elementos debe ser NO replicable y NO reutilizable.
  • No susceptible de ser robado a través de Internet.

Llegado este punto y considerando los métodos usados actualmente en la banca online minorista y el comercio electrónico, nos atrevemos a decir que salvo excepciones, ninguna organización cumple hoy en su totalidad estos requisitos. Por ejemplo, la mayor parte de las implantaciones basadas en contraseñas de un sólo uso (OTP) enviadas por SMS y/o en tarjetas de coordenadas no cumplirían con estos requisitos.

Algunas consideraciones

No cabe duda de que la Autenticación Reforzada tal como se define en la directiva supone un nivel de seguridad excelente; si embargo, dependiendo de cómo se implemente, puede tener un alto impacto en la conveniencia del usuario. La propia EBA reconoce además que pueden existir dificultades técncias para poder cumplir con estos requisitos en algunos casos y se espera que sobre algunos de los puntos se dé una mayor claridad y flexibilidad en el futuro estándar que emitirá. Comentemos aquí brevemente algunas de estas dificultades:

Requisito de Independencia

Como hemos visto, el requisito de independencia hace referencia a aquella condición por la que el compromiso o vulneración de uno de los elementos usados en la Autenticación Reforzada no implica el compromiso de los otros elementos. Este requisito suele ser asimilado por algunos profesionales de la seguridad a la independencia de los canales; es decir, a situaciones en donde el canal de autenticación es independiente de aquel por donde se esá realizando la operación; por ejemplo, en escenarios en donde el usuario inicia la orden de pago desde el navegador web y valida la operación por un canal paralelo; por ejemplo, a través de una contraseña de un solo uso (OTP) generada (e incluso validada) por medio del teléfono móvil. Personalmente, creo que esta asimilación es realizada a veces de manera interesada por los vendedores de determinadas soluciones de seguridad. Algunos pensamos que el requisito de independencia se cumpliría aunque la validación final del código de un sólo uso se lleve a cabo en el mismo canal en donde se imputa la orden de pago, siempre que el código haya sido generado / recbido en un componente distinto; por ejemplo, un OTP recibido en el móvil por SMS.

Sea como fuere, la posibilidad de cumplir con este requisito se complica si uno considera que el uso del teléfono móvil (celular) se está imponiendo como canal para la realización de operaciones de pago  y que al mismo tiempo el móvil se está usando cada vez más como elemento de seguridad de estas operaciones (por ejemplo, para la recepción o generación de OTP). En este caso hay una concurrencia entre el canal de inicio de la orden y el de generación de la credencial de validación. En pureza podría considerarse, salvo que la EBA clarifique o flexibilize este requisito, que esto compromete el criterio de independencia de los elementos de autenticación y siendo esto así, la única alternativa posible en el caso de los pagos iniciados por móvil, será dotar a los usuarios de mecanismos de autenticación distintos al teléfono; por ejemplo, generadores de token físicos; lo cual, además de suponer un considerable incremento en el coste del servicio, tendría un impacto muy significativo en la usabilidad de la solución y la conveniencia de los usuarios.

digipass

Seguridad del SMS

Actualmente, uno de los mecanismos usados de manera generalizada por la industria es el envío de contraseñas de validación de operaciones de un sólo uso (OTP) por medio de mensajes SMS al teléfono del usuario. El canal SMS no permite garantizar la confidencialidad de las credenciales, como se ha puesto de manifiesto en diferentes escenarios de robo de credenciales mediante el secuestro del SMS. Salvo que la EBA diga lo contrario, las entidades que usan este mecanismo, deberán empezar a pensar en sustituirlo ya que no se puede garantizar la confidencialidad de la credencial.

Protección de las credenciales de seguridad y la privacidad de los datos del cliente a lo largo de la cadena de pago

En este sentido, la EBA deberá clarificar estas cuestiones; especialmente cómo se certificará por parte de terceros independientes la seguridad de los canales de comunicación y de los sistemas que almacenan, procesan y transmitan credenciales o datos del usuario.

Vinculación dinámica de los datos de importe y beneficiario del pago con el elemento de autenticación

Este requisito, implica que el código de validación OTP de un sólo uso esté vinculado a los datos de la operación específica. Para ello, en su cálculo se deben tomar como variables de entrada datos como la fecha y hora de la operación, el  beneficiario del pago y el importe. Con éste método, el OTP generado no puede ser usado para validar ninguna otra operación distinta, lo que invalida aquellos ataques sofisticados en los que el troyano que infecta el dispositivo del usuario aprovecha una operación iniciada legítimamente por el cliente, para modificar de manera encubierta los datos de la operación sin que la vícitma se de cuenta de ello y valide sin saberlo una operación distinta a la que pretendía. Sin duda este requisito establece un muy alto nivel de seguridad; sin embargo, dependiendo de cómo se implemente, el impacto en la conveniencia del usuario / usabilidad puede ser alto y la efectividad a la hora de prevenir ataques puede variar.

Acceso online a la cuenta de pago

Creemos que la EBA debería aclarar este requisito. ¿Significa que el mero acceso a la banca online, aún cuando se trate de un acceso de sólo consulta debería requerir Autenticación Fuerte?. La interpretación más generalizada es que en el acceso inicial debería requerirse un segundo factor de autenticación sólo en el caso de que se visualizen datos sensibles como puede ser el PAN de la tarjeta y la Fecha de Caducidad; es decir, datos que permitirían la comisión de fraude. Sin embargo, la indefinición del concepto de “datos sensibles” podría llevar a interpretaciones más extremas.

Exenciones

El artículo 98.3 de las PSD2 establece los siguientes criterios como base para excepcionar la aplicación del requisito de Autenticación Reforzada:

  • El nivel de riesgo del servicio;
  • La cantidad / recurrencia de la transacción;
  • El canal de pago.

Es decir, se abre la vía para que la Autenticación Reforzada sea de aplicación sólo en aquellas situaciones de mayor riesgo. Parece que tiene sentido modular en función del riesgo en cada caso. Aunque la PSD2 no da más detalle al respecto, la EBA podría clarificar más estos criterios. Algunas posibles exenciones que están bajo discusión son:

  • En caso de pagos de bajo importe, suponiendo que se tenga en cuenta el importe acumulado en distintas operaciones;
  • En casos donde los pagos se realizan a cuentas / beneficiarios considerados de confianza por parte del cliente; Por ejemplo, aquellos que el cliente haya incluido en una “lista blanca” de cuentas confiables…
  • Traspasos de fondos entre cuentas del mismo cliente en el mismo procesador de servicios de pago (ej: el mismo banco);
  • Transferencias clasificadas de bajo riesgo, a partir del análisis del riesgo de la transacción concreta;
  • Servicios de sólo consulta en los que no se muestren datos sensibles del pago.

Cerramos aquí esta breve reseña. Esperamos que el futuro estándar técnico de la EBA ayudará a clarificar estos y algunos otros puntos y que, dando cabida al sentido común, lleve a un entorno de pagos por Internet seguro y conveniente tanto para los conusmidores y las empresas.

Sin más, un fuerte abrazo y hasta pronto.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s