3D Secure

3-D Secure es un protocolo basado en XML diseñado para ser una capa de seguridad adicional para transacciones de tarjetas de crédito y débito en línea. Originalmente fue desarrollado por Arcot Systems (ahora CA Technologies) y primero desplegado ^[1]​ por Visa con la intención de mejorar la seguridad de los pagos por Internet, y se ofrece a los clientes bajo las marcas Verified by Visa/Visa Secure. Los servicios basados en el protocolo también han sido adoptados por Mastercard como SecureCode, Discover como ProtectBuy ^[2]​ y por JCB International como J/Secure. American Express agregó 3-D Secure en mercados seleccionados el 8 de noviembre de 2010 como American Express SafeKey, y continúa lanzando mercados adicionales. ^[3]​

EMV 3-D Secure Three-Domain Secure (3DS) es un protocolo de mensajería desarrollado por EMVCo para permitir a los consumidores autenticarse con el emisor de su tarjeta al realizar transacciones con tarjeta no presente (CNP). La capa de seguridad adicional ayuda a evitar transacciones CNP no autorizadas y protege al comerciante de la exposición de CNP al fraude. Los tres dominios Secure consisten en el dominio del comerciante / adquirente, el dominio del emisor y el dominio de interoperabilidad (p. Ej. Sistemas de pago). ^[4]​

El análisis de la primera versión del protocolo por parte de la academia ha demostrado que tiene muchos problemas de seguridad que afectan al consumidor, incluida una mayor superficie de phishing y un cambio de responsabilidad en el caso de pagos fraudulentos. ^[5]​

Descripción y aspectos básicos

El concepto básico del protocolo es vincular el proceso de autorización financiera con la autenticación en línea. Esta autenticación de seguridad adicional se basa en un modelo de tres dominios (de ahí el 3-D en el nombre mismo). Los tres dominios son:

• Dominio del adquirente (el banco y el comerciante al que se paga el dinero).
• Dominio del emisor (el banco que emitió la tarjeta que se está utilizando).
• Dominio de interoperabilidad (la infraestructura proporcionada por el esquema de tarjeta, crédito, débito, prepago u otro tipo de tarjeta de pago, para soportar el protocolo 3-D Secure). Incluye Internet, el complemento comercial, el servidor de control de acceso y otros proveedores de software.

El protocolo utiliza mensajes XML enviados a través de conexiones SSL con autenticación de cliente ^[6]​ (esto garantiza la autenticidad de ambos pares, el servidor y el cliente, utilizando certificados digitales).

Una transacción que utilice Verified-by-Visa o SecureCode iniciará una redirección al sitio web del banco emisor de la tarjeta para autorizar la transacción. Cada emisor podría usar cualquier tipo de método de autenticación (el protocolo no cubre esto) pero, por lo general, se ingresa una contraseña vinculada a la tarjeta al realizar compras en línea. El protocolo Verified-by-Visa recomienda que la página de verificación del banco se cargue en una sesión de marco en línea. De esta manera, los sistemas del banco pueden ser responsables de la mayoría de las violaciones de seguridad. Hoy es fácil enviar una contraseña de un solo uso como parte de un mensaje de texto SMS a los teléfonos móviles y correos electrónicos de los usuarios para la autenticación, al menos durante la inscripción y para las contraseñas olvidadas.

La principal diferencia entre las implementaciones de Visa y Mastercard radica en el método para generar el UCAF (campo de autenticación del titular de la tarjeta universal): Mastercard usa AAV (Valor de autenticación del titular de la cuenta) y Visa usa CAVV (Valor de verificación de autenticación del titular de la tarjeta). ^{[aclaración requerida]}

 

Flujo 3-D Secure

Implementaciones

Las especificaciones están actualmente en la versión 1.0.2. Las versiones anteriores 0.7 (solo utilizadas por Visa USA) y 1.0.1 han quedado obsoletas y ya no son compatibles. Mastercard y JCB han adoptado la versión 1.0.2 del protocolo solamente.

Para que un banco miembro de Visa o Mastercard use el servicio, el banco debe operar un software compatible que admita las últimas especificaciones de protocolo.

Proveedores de ACS

En el protocolo 3-D Secure, el ACS (servidor de control de acceso) está en el lado del emisor (bancos). Actualmente, la mayoría de los bancos subcontratan el ACS a un tercero. Comúnmente, el navegador web del comprador muestra el nombre de dominio del proveedor de ACS, en lugar del nombre de dominio del banco; sin embargo, esto no es requerido por el protocolo. Dependiendo del proveedor de ACS, es posible especificar un nombre de dominio propiedad del banco para uso de ACS.

Proveedores de MPI

Cada transacción de 3-D Secure versión 1 involucra dos pares de solicitud / respuesta de Internet: VEReq / VERes y PAReq / PARes. ^[7]​ Visa y Mastercard no permiten que los comerciantes envíen solicitudes directamente a sus servidores. Los comerciantes deben utilizar en su lugar proveedores de MPI (merchant plug-in).

Comerciantes

La ventaja para los comerciantes es la reducción de los contracargos por "transacciones no autorizadas". Una desventaja para los comerciantes es que tienen que contratar un merchant plug-in (MPI) para conectarse al servidor de directorio Visa o Mastercard. Esto es costoso ^{[aclaración requerida]} (tarifa de instalación, tarifa mensual y tarifa por transacción); Al mismo tiempo, representa ingresos adicionales para los proveedores de MPI. Apoyar 3-D Secure es complicado y, a veces, crea fallas en las transacciones. Quizás la mayor desventaja para los comerciantes es que muchos usuarios ven el paso de autenticación adicional como una molestia u obstáculo, lo que resulta en un aumento sustancial en el abandono de transacciones y la pérdida de ingresos. ^[8]​

Compradores y titulares de tarjetas de crédito

La intención detrás del sistema es reducir el riesgo de que las personas puedan usar las tarjetas de pago de otras personas de manera fraudulenta en Internet.

En la mayoría de las implementaciones actuales de 3-D Secure, el banco emisor o su proveedor ACS solicita al comprador una contraseña que solo el banco / proveedor ACS y el comprador conocen. Dado que el comerciante no conoce esta contraseña y no es responsable de capturarla, el banco emisor puede usarla como evidencia de que el comprador es efectivamente el titular de su tarjeta. Esto tiene la intención de ayudar a disminuir el riesgo de dos maneras:

1. Copiar los detalles de la tarjeta, ya sea escribiendo los números en la tarjeta o por medio de terminales o cajeros automáticos modificados, no da la posibilidad de comprar por Internet debido a la contraseña adicional, que no está almacenada ni escrita en la tarjeta .
2. Dado que el comerciante no captura la contraseña, existe un menor riesgo de incidentes de seguridad en los comerciantes en línea; Si bien un incidente aún puede provocar que los piratas informáticos obtengan otros detalles de la tarjeta, no hay forma de que obtengan la contraseña asociada.

3-D   Secure no requiere estrictamente el uso de autenticación de contraseña. Se dice que es posible ^{[cita requerida]} para usarlo junto con lectores de tarjetas inteligentes, tokens de seguridad y similares. Estos tipos de dispositivos pueden proporcionar una mejor experiencia de usuario para los clientes, ya que liberan al comprador de tener que usar una contraseña segura. Algunos emisores ahora están utilizando dichos dispositivos como parte del Programa de autenticación de chip o los esquemas de autenticación de código de acceso dinámico. ^{[cita requerida][ <span title="This claim needs references to reliable sources. (September 2011)">cita requerida</span> ]} Una desventaja significativa es que es probable que los titulares de tarjetas vean que su navegador se conecta a nombres de dominio desconocidos como resultado de las implementaciones de MPI de los proveedores y el uso de implementaciones de ACS subcontratadas por los bancos emisores, lo que podría facilitar la realización de ataques de phishing en los titulares de tarjetas.

American Express SafeKey

American Express SafeKey está disponible en los siguientes mercados: Argelia, Australia, Austria, Baréin, Bangladés, China, Chipre, Egipto, Finlandia, Francia, Alemania, Grecia, Hong Kong, India, Irak, Italia, Japón, Jordania, Kenia, Kuwait, Líbano, Lesoto, Libia, Malasia, Mauritania, México, Mongolia, Marruecos, Namibia, Países Bajos, Nueva Zelanda, Omán, Perú, Filipinas, Qatar, Rusia, San Marino, Singapur, Somalia, Sudáfrica, España, Sri Lanka, Suecia, Suiza, Tanzania, Túnez, Turquía, Emiratos Árabes Unidos, Uganda, Reino Unido, Ciudad del Vaticano, Vietnam, Yemen. ^[9]​

Crítica general

Verificabilidad de la identidad del sitio

El sistema involucra una ventana emergente o un marco en línea que aparece durante el proceso de la transacción en línea, requiriendo que el titular de la tarjeta ingrese una contraseña que, si la transacción es legítima, el banco emisor de la tarjeta podrá autenticar. El problema para el titular de la tarjeta es determinar si la ventana emergente o el marco es realmente del emisor de su tarjeta, cuando podría ser de un sitio web fraudulento que intenta obtener los detalles del titular de la tarjeta. Tales ventanas emergentes o marcos basados en scripts carecen de acceso a cualquier certificado de seguridad, eliminando cualquier forma de confirmar las credenciales de la implementación de 3-DS.

El sistema Verified-by-Visa ha generado algunas críticas, ^[10]​ ^[11]​ ^[12]​ ^[13]​ ya que es difícil para los usuarios diferenciar entre la ventana emergente legítima Verified-by-Visa o el marco en línea, y un sitio de phishing fraudulento. Esto se debe a que la ventana emergente se sirve desde un dominio que:

• No es el sitio donde el usuario está comprando
• No es el banco emisor de la tarjeta
• No es visa.com o mastercard.com

En algunos casos, los usuarios han confundido el sistema Verified-by-Visa con una estafa de phishing ^[14]​ y se ha convertido en el objetivo de algunas estafas de phishing. ^[15]​ La recomendación más reciente de usar un marco en línea (iframe) en lugar de una ventana emergente ha reducido la confusión del usuario, a costa de hacer que sea más difícil, si no imposible, que el usuario verifique que la página sea genuina en primer lugar. A partir de 2011, [necesita actualización] la mayoría de los navegadores web no proporcionan una forma de verificar el contenido de un iframe en el certificado de seguridad. Sin embargo, algunas de estas inquietudes sobre la validez del sitio para Verified-by-Visa se mitigan, ya que su implementación actual del proceso de inscripción requiere ingresar un mensaje personal que se muestra en las ventanas emergentes de Verified-by-Visa para brindar cierta seguridad al usuario las ventanas emergentes son genuinas. ^[16]​

Algunos emisores de tarjetas también usan la activación durante la compra (ADS), ^[17]​ en la que los titulares de tarjetas que no están registrados en el esquema tienen la oportunidad de registrarse (o ser obligados a registrarse) durante el proceso de compra. Por lo general, esto los llevará a una forma en la que se espera que confirmen su identidad respondiendo preguntas de seguridad que el emisor de su tarjeta debe conocer. Una vez más, esto se hace dentro del iframe, donde no pueden verificar fácilmente el sitio al que están brindando esta información: un sitio agrietado o un comerciante ilegítimo podría reunir de esta manera todos los detalles que necesitan para hacerse pasar por el cliente.

La implementación de 3-D Secure a menudo no permite a un usuario continuar con una compra hasta que haya acordado registrarse en el protocolo y sus términos y condiciones, y de esta manera no ofrece ninguna forma alternativa de navegar fuera de la página que cerrarla, suspendiendo así la transacción.

Los titulares de tarjetas que no estén dispuestos a correr el riesgo de registrar su tarjeta durante una compra, con el sitio de comercio controlando el navegador hasta cierto punto, en algunos casos pueden ir a la página de inicio de su banco en la web en una ventana separada del navegador y registrarse desde allí. Cuando regresen al sitio de comercio y comiencen de nuevo, deberían ver que su tarjeta esté registrada. La presencia en la página de contraseña del mensaje de seguridad personal (PAM) que eligieron al registrarse es su confirmación de que la página proviene del banco. Esto todavía deja alguna posibilidad de un ataque de hombre en el medio si el titular de la tarjeta no puede verificar el certificado del servidor SSL para la página de contraseña. Algunos sitios de comercio dedicarán la página completa del navegador a la autenticación en lugar de usar un marco (no necesariamente un iFrame), que es un objeto menos seguro. En este caso, el ícono de candado en el navegador debe mostrar la identidad del banco o del operador del sitio de verificación. El titular de la tarjeta puede confirmar que está en el mismo dominio que visitó al registrar su tarjeta si no es el dominio de su banco.

Los navegadores móviles presentan problemas particulares para 3-D Secure, debido a la falta común de ciertas características, como marcos y ventanas emergentes. Incluso si el comerciante tiene un sitio web móvil, a menos que el emisor también tenga conocimiento móvil, las páginas de autenticación pueden fallar al representarse correctamente, o incluso en absoluto. Al final, muchos analistas han concluido que los protocolos de activación durante la compra (ADS) invitan a un mayor riesgo del que eliminan y además transfieren este mayor riesgo al consumidor.

En algunos casos, 3-D Secure termina proporcionando poca seguridad al titular de la tarjeta, y puede actuar como un dispositivo para transferir la responsabilidad por transacciones fraudulentas del banco o comercio al titular de la tarjeta. Las ondiciones legales aplicadas al servicio 3-D Securea veces están redactadas de una manera que dificultan al titular de la tarjeta escapar de la responsabilidad de transacciones fraudulentas de "titular de la tarjeta no presente". ^[18]​

Discriminación geográfica

Los bancos y comerciantes pueden usar los sistemas de 3-D Secure de manera desigual con respecto a los bancos que emiten tarjetas en varias ubicaciones geográficas, creando una diferenciación, por ejemplo, entre las tarjetas nacionales emitidas en EE. UU. Por ejemplo, dado que Visa y Mastercard tratan el territorio estadounidense no incorporado de Puerto Rico como una ubicación internacional no estadounidense, en lugar de local, los titulares de tarjetas pueden enfrentar una mayor incidencia de consultas 3-D   Secure que los titulares de tarjetas en los cincuenta estados. Las quejas a ese efecto han sido recibidas por el sitio de discriminación económica "igualdad de trato" del Departamento de Asuntos del Consumidor de Puerto Rico . ^[19]​

3-D Secure como autenticación de cliente fuerte

La variante más nueva de 3-D Secure, que incorpora contraseñas de un solo uso, es una forma de autenticación de cliente fuerte basada en software. Sin embargo, la variante heredada con contraseñas estáticas no cumple con los requisitos de enero de 2013 del Banco Central Europeo (BCE).

3-D Secure depende de que el emisor participe activamente y se asegure de que cualquier tarjeta emitida sea registrada por el titular de la tarjeta, lo que la convierte en una solución centrada en el problema.

El BCE ha ordenado en sus requisitos de enero de 2013 "Seguridad para pagos por Internet" ^[20]​ que todas las transacciones adquiridas dentro del Área Única de Pago en Euros (SEPA) deben autenticarse utilizando una autenticación fuerte del cliente antes del 1 de febrero de 2015. Este mandato del BCE, y respaldado por la Segunda Directiva de Servicios de Pago de la Comisión Europea Mk2 (PSD2), tiene como objetivo proporcionar un campo de juego nivelado y tecnológicamente neutral dentro de SEPA para fomentar el comercio electrónico, el comercio móvil y las tecnologías de apoyo, incluidas formas competitivas de autenticación de cliente fuerte.

Como 3-D Secure se basa en la participación anticipada del emisor y la inscripción de tarjetas, los adquirentes no pueden confiar en 3-D Secure para cumplir con los requisitos de autenticación del lado adquirente, hasta que 3-D Secure tenga un enrolamiento significativo que se acerque al 100% de todas las tarjetas emitidas .

Esto, a su vez, hace que 3-D Secure sea una solución débil para los requisitos de autenticación de cliente fuerte del lado adquirente, particularmente porque 3-D Secure no está disponible en los 25 esquemas de tarjetas más pequeños reconocidos por el BCE. 3-D Secure también debe implementarse para cada esquema de tarjeta al que se aplicará, generalmente caso por caso, a menos que se utilice una empresa de integración especializada.

Por lo tanto, los adquirentes pueden enfrentarse a aceptar tarjetas que no están suscriptas y son susceptibles de fraude, o de rechazar dichas tarjetas hasta que esté disponible un medio de autenticación fuerte del cliente. Dado que los compradores y las pasarelas de pago son responsables del fraude en sus redes a partir del 1 de febrero de 2015, a menos que cuenten con una autenticación del cliente fuerte, no está claro qué impacto tendrán los requisitos del BCE en el comercio electrónico SEPA.

La autenticación del lado adquirente difiere de la autenticación del lado emisor, en el sentido de que las tarjetas se inscriben al ser adquiridas como parte de una transacción, en lugar de requerir un prerregistro después del problema. La autenticación del lado adquirente puede, por lo tanto, inscribir tarjetas progresivamente a pedido, logrando una tasa de inscripción efectiva del 100%. La inscripción y la autenticación de la tarjeta pueden ser al mismo tiempo.

Los ejemplos de autenticación del lado adquirente incluyen el método patentado de 'verificación' ^[21]​ PayPal, donde una o más transacciones ficticias se dirigen a una tarjeta de crédito, y el titular de la tarjeta debe confirmar el valor de estas transacciones. El método patentado por iSignthis ^[22]​ utiliza el valor de la transacción en el punto de venta, de modo que el monto de las ventas acordado entre el comercio electrónico y el titular de la tarjeta, se divide en dos (o más) montos, siendo el primer monto un valor generado aleatoriamente, y el segundo valor es el importe de equilibrio entre el importe de ventas y el valor aleatorio.

Ambos métodos se basan en que el titular de la tarjeta acceda a la cuenta asociada con la tarjeta de crédito y confirme el valor de la transacción aleatoria para demostrar que es el propietario de la cuenta. Sin embargo, el método de PayPal no se relaciona específicamente con una transacción entre un comercio electrónico y el titular de la tarjeta, por lo que, a menos que se aumente con otro proceso que se relacione directamente con una transacción, el método no es una forma de autenticación fuerte del cliente, por lo que no es una alternativa a 3-D Secure. ^[23]​

ACCC bloquea la propuesta de 3-D Secure

La Comisión Australiana de la Competencia y el Consumidor (ACCC) bloqueó una propuesta de hacer obligatorio 3-D Secure en Australia después de recibir numerosas objeciones y presentaciones relacionadas con fallas. ^[24]​

3-D Secure 2.0

En octubre de 2016, EMVCo publicó la especificación para 3-D Secure 2.0; está diseñado para ser menos intrusivo que la primera versión de la especificación, lo que permite enviar más datos contextuales al banco del cliente (incluidas las direcciones de correo y el historial de transacciones) para verificar y evaluar el riesgo de la transacción. El cliente solo debería pasar un desafío de autenticación si se determina que su transacción es de alto riesgo. Además, el flujo de trabajo para la autenticación está diseñado para que ya no requiera redireccionamientos a una página separada, y también pueda activar la autenticación fuera de banda a través de la aplicación móvil de una institución (que, a su vez, también se puede usar con autenticación biométrica). 3-D Secure 2.0 cumple con los mandatos de " autenticación de cliente fuerte " de la UE. ^[25]​ ^[26]​ ^[27]​

Ver también

• Transacción electrónica segura (SET)
• Merchant plug-in (MPI)

Referencias

1. «Visa USA tightens security with Arcot». ZDnet. 
2. . discover.com. Archivado desde el original el 22 de agosto de 2019. Consultado el 4 de junio de 2020. 
3. . AmericanExpress.com. Archivado desde el original el 7 de agosto de 2011. Consultado el 11 de agosto de 2010. 
4. https://www.emvco.com/emv-technologies/3d-secure/
5. «Verified by Visa and MasterCard SecureCode: or, How Not to Design Authentication». 
6. http://people.sabanciuniv.edu/levi/cs432/xxspring%202008%20fsdfgsd/3D_Secure_Emre_Kaplan.pdf
7. «Verified by Visa Implementation Guide». 
8. «Are Verified by Visa and MasterCard SecureCode Conversion Killers?». practicalecommerce.com. Consultado el 30 de julio de 2013.  This 2010 study documented increases in the number of abandoned transactions of 10% to 12% for merchants newly joining the program.
9. «Home | American Express SafeKey». Network.americanexpress.com. Consultado el 2 de marzo de 2015. 
10. «Antiworm: Verified by Visa (Veriphied Phishing?)». Antiworm.blogspot.com. 2 de febrero de 2006. Consultado el 11 de agosto de 2010. 
11. Muncaster, Phil. . IT Week. Archivado desde el original el 7 de octubre de 2008. Consultado el 11 de agosto de 2010. 
12. Brignall, Miles (21 de abril de 2007). «Verified by Visa scheme confuses thousands of internet shoppers». London. Consultado el 23 de abril de 2010. 
13. «Verified by Visa and MasterCard SecureCode: or, How Not to Design Authentication» (PDF). Consultado el 11 de agosto de 2010. 
14. . Ambrand.com. Archivado desde el original el 16 de junio de 2010. Consultado el 11 de agosto de 2010. 
15. . MillerSmiles.co.uk. 22 de agosto de 2006. Archivado desde el original el 8 July 2010. Consultado el 11 de agosto de 2010. 
16. «Verified by Visa FAQs». www.visa.co.uk. Consultado el 6 de octubre de 2016. 
17. «Activation During Shopping». Visaeurope.com. Consultado el 11 de agosto de 2010. 
18. «Verified by Visa and MasterCard SecureCode: or, How Not to Design Authentication» (PDF). Consultado el 23 de abril de 2012. 
19. . daco.pr.gov. Archivado desde el original el 12 de agosto de 2014. Consultado el 17 de julio de 2014. 
20. https://www.ecb.europa.eu/press/pr/date/2013/html/pr130131_1.en.html
21. «US2001021725 System and Method for Verifying a Financial Instrument». Patentscope.wipo.int. 17 de enero de 2002. Consultado el 17 de julio de 2014. 
22. «AU2011000377 Methods and Systems for Verifying Transactions». Patentscope.wipo.int. Consultado el 17 de julio de 2014. 
23. «EPCA Payment Summit: iSignthis presents its authentication service as an alternative to 3D Secure». The Paypers. Consultado el 17 de julio de 2014. 
24. «ACCC Releases Draft Determination Against Mandated Use Of 3D Secure For Online Payments». 
25. «Merchants can't let 'PSD2' and 'SCA' be vague initials». PaymentsSource (en inglés). Consultado el 11 de julio de 2019. 
26. «Adyen Touts Its 3-D Secure 2.0 Service As "First" to Market». Digital Transactions (en inglés estadounidense). Consultado el 11 de julio de 2019. 
27. Godement, Olivier. «Stripe: 3D Secure 2 - Guide to 3DS2 Authentication» (en inglés). Stripe. Consultado el 11 de julio de 2019. 

Enlaces externos

• American Express SafeKey (sitio del consumidor)
• American Express SafeKey (sitio global asociado)
• Verificado por Visa
• Página de inicio de Mastercard SecureCode
• usa.visa.com

•   Datos: Q223074