Entrevista con el ingeniero de certificación senior de FIDO Alliance para la autenticación sin contraseña
Nuestros usuarios nos pidieron que implementemos la autenticación de dos factores a través de la aplicación Google. Y recientemente, les hemos
dado esta oportunidad. Casi al mismo tiempo, el consorcio FIDO Alliance publicó estándares para la autenticación sin contraseña en sitios, aplicaciones móviles y servicios web: WebAuthn y CTAP.
Nos interesamos en este tema y
preparamos material sobre Habré , en el que hablamos sobre los métodos que subyacen a los nuevos protocolos.
Luego, para aclarar algunos puntos con respecto a las complejidades de la norma, hablamos con Yuri Akkermann (
herrjemand ), ingeniero de certificación senior de FIDO Alliance. Respondió varias de nuestras preguntas sobre la autenticación pasada, presente y futura de FIDO. Les presentamos el texto de la entrevista.
/ Flickr / zhrefch / PDCuéntenos sobre sus antecedentes y experiencia en el campo de TI en general. ¿Cómo empezaste tu trabajo en la industria?
He estado haciendo programación desde que tenía quince años. Después de la escuela, fui a la universidad, donde estudié informática y matemáticas. En el segundo año me interesé por la criptografía, los problemas de seguridad de la información y me topé con FIDO. Realmente me gustaron sus protocolos, y al final escribí una biblioteca U2F para Python Flask e hice una presentación.
Mi trabajo fue apreciado por FIDO. Además, solo buscaban un ingeniero de certificación. Al final, me hice responsable de la certificación técnica.
¿Cuánto tiempo llevas lidiando con temas relacionados con la autenticación con FIDO? ¿Qué tareas resolvió en el proceso de desarrollo de un nuevo estándar?
He estado trabajando con los protocolos FIDO durante tres años, dos de ellos en la Alianza FIDO. Mi función principal es la certificación técnica y las herramientas automatizadas para probar implementaciones según las especificaciones. Mis responsabilidades incluyen el desarrollo y soporte de las herramientas en sí mismas, así como la redacción de planes de prueba: listas de prueba para verificar servidores, clientes y autenticadores. Creo que escribir un plan de prueba es el proceso que requiere más tiempo, ya que requiere una comprensión de todas las complejidades de los protocolos y los estándares utilizados en ellos.
También asesoro a grupos de trabajo sobre posibles mejoras en las especificaciones, realizo presentaciones y escribo artículos de vez en cuando.
¿Cómo nació la idea de crear un nuevo estándar para la autenticación? ¿Por qué decidiste que el mundo y la comunidad necesitan una nueva solución en esta área? ¿Cuáles son las desventajas de los formatos existentes que WebAuthn pretende cerrar?
FIDO Alliance fue fundada en 2013 por Agnitio, Infineon Technologies, Lenovo, Nok Nok Labs, PayPal y Validity, que desarrollaron UAF. Poco después, Google, Yubico y NXP se unieron a ellos; estos trabajaron en el predecesor de U2F y pensaron que sería rentable unir fuerzas, ya que sus ideas coincidían con las ideas de la Alianza. Intentaron proteger a los usuarios de Internet del phishing, resolver los problemas de usabilidad de las contraseñas y también desarrollar la accesibilidad y seguridad de las tecnologías biométricas.
¿Se han llevado a cabo estudios preliminares que hayan fortalecido la intención de crear un estándar o hayan impulsado su creación? Si es así, ¿qué tipo de datos analizó?
Los miembros de la alianza como Google, Microsoft, Samsung, Yubico y otros están trabajando activamente para crear y promover estándares. Están explorando mercados, tratando de entender cómo FIDO puede "encajar" en varios ecosistemas. Google, por ejemplo,
realizó un estudio sobre la migración del segundo factor de contraseñas de un solo uso a U2F.
¿Cómo nació el protocolo CTAP? ¿Cómo se asocia con WebAuthn?
FIDO consta de tres partes: servidor, cliente (navegador) y autenticador. El servidor envía una llamada al cliente, el cliente pasa la llamada al autenticador, quien la firma y la devuelve al cliente, y esa ya está enviada al servidor.
Para que el servidor use la autenticación FIDO, los clientes tienen una API WebAuthn JS. El cliente se comunica con los autenticadores utilizando el protocolo de bajo nivel CTAP2 (Protocolo 2 de cliente a autenticador). CTAP2 describe las estructuras de consulta CBOR y los transportes, como USB, NFC y BLE para comunicarse con un autenticador. La combinación de estos dos estándares se llama FIDO2.
Uno de los objetivos de crear el formato es proteger contra el phishing. ¿Cuáles son algunas de las ventajas en comparación con otras soluciones?
Si hablamos de soluciones existentes, lo único con lo que FIDO se puede comparar son los certificados de cliente o TLS CCA (Autenticación de certificado de cliente). FIDO y CCA son protocolos seguros de phishing de respuesta a llamadas en claves públicas. Pero tienen diferencias significativas.
Las CCA no están protegidas de un ataque de repetición. Reutilizan un solo certificado en múltiples sitios, lo que puede conducir a la desanonimización del usuario. En FIDO, generamos un nuevo par de claves único para cada registro con el fin de mantener la privacidad.
CCA también tiene un problema con el almacenamiento de claves, ya que en la mayoría de los casos la clave privada está encriptada en PKCS12 o simplemente queda en claro. Por lo tanto, incluso una aplicación sin privilegios puede robarla sin problemas. En FIDO, todas las claves se mantienen seguras, por ejemplo, en el almacenamiento unidireccional de SecureEnclave. Recuperar claves de este tipo de almacenamiento es muy difícil.
CCA tiene dificultades con la implementación adecuada en el lado del servidor, ya que el soporte completo de CCA deja mucho que desear. Y debido a las complejidades de trabajar con TLS, los desarrolladores cometen muchos errores. FIDO solo necesita soporte para la criptografía básica en sí. CCA se puede implementar a través de HTTP, lo que no se puede hacer en WebAuthn. CCA también tiene problemas de portabilidad y facilidad de uso.
No creo que la Alianza haya inventado nada nuevo. Simplemente desarrollamos un buen protocolo que incluye los mecanismos de seguridad existentes.
/ Flickr / markus spiske / PD¿El uso del estándar abrirá vectores de ataque adicionales relacionados con el hecho de que será necesario almacenar una gran cantidad de información biométrica?
Uno de nuestros principios fundamentales es la privacidad. La información biométrica se almacena en chips seguros y nunca los abandona. Nuestras empresas trabajan con lectores certificados por FIDO o FIPS.
Tampoco utilizamos información biométrica para nada más que para confirmar la presencia del usuario. Y tenemos un programa de certificación biométrica para probar autenticadores.
Una vez dijo que la autenticación por código SMS es una mala opción de 2FA. ¿Cómo puedes comentar esto?
Los códigos SMS o SMS OTP son autenticación de dos factores con contraseñas de un solo uso entregadas por SMS. Por lo tanto, resulta que esta solución es vulnerable al phishing. Si su usuario está atrapado en phishing y le da su nombre de usuario y contraseña, ¿qué le impedirá transmitir un código SMS a los cibercriminales?
No debemos olvidarnos de los problemas de usar SMS como transporte. Hace tres años, 400 mil cuentas fueron pirateadas en un banco alemán debido a una vulnerabilidad en el protocolo SS7, que se utiliza para enrutar información de telecomunicaciones entre diferentes operadores de telecomunicaciones. Los atacantes que obtuvieron acceso no autorizado a la red SS7, en la que no hay autenticación, pudieron registrar los números de las víctimas y obtener sus códigos.
Además, hoy cualquiera puede comprar una estación base GSM por $ 500-600 e interceptar SMS usando un ataque MITM. Y finalmente, hay peligros asociados con la ingeniería social. Creo que muchos
están familiarizados con la historia cuando los atacantes robaron una cantidad sustancial de dinero de las cuentas bancarias al emitir un duplicado de la tarjeta SIM de la víctima. Esto sucede en Rusia y otros países con envidiable regularidad.
¿Qué sucede si necesita ingresar al servicio en varios dispositivos o si varias personas usan el mismo servicio a la vez? ¿El estándar admite este modo de operación?
A diferencia de una contraseña, puede haber muchos autenticadores. El usuario puede registrar su teléfono, computadora portátil, token y usar cualquiera de ellos para la autenticación. Además, un token se puede "vincular" a varias cuentas sin pérdida de privacidad.
Pero, ¿y si se perdiera la ficha? ¿Será posible devolver el acceso a los servicios?
La autenticación FIDO debe considerarse como claves de inicio. Si ha perdido sus llaves, siempre puede recoger el repuesto de su esposa, hijos, madre, abuela o, en el peor de los casos, sacarlos de debajo del tapete de la puerta. Por lo tanto, le recomendamos que siempre tenga un identificador de repuesto y lo guarde, por ejemplo, en una caja fuerte.
Si hablamos de restaurar el acceso a los servicios, entonces este es realmente un problema difícil. La recuperación no es parte del estándar, porque diferentes recursos restauran el acceso a las cuentas de diferentes maneras. Los enfoques clásicos son códigos únicos que no están protegidos contra el phishing. Facebook le permite recuperar el acceso a través de amigos.
La solución más prometedora hasta la fecha es
Delegated Recovery , un protocolo de recuperación basado en el almacenamiento de secretos cifrados en otros servicios. Por cierto, fue escrito por uno de los creadores de U2F Bratt Hill (Bratt Hill). La recuperación es un problema bastante difícil e interesante, cuya solución queda por encontrar.
La clave privada en el autenticador debe estar protegida contra copia. ¿De qué forma y dónde se almacenan los identificadores? ¿Cómo se intercambian?
En cada registro, el autenticador genera un nuevo par de claves único y le asigna un identificador aleatorio llamado ID de credencial o ID de crédito. Las claves privadas se almacenan en un almacenamiento seguro, como SecureEnclave, TPM o TEE.
La clave privada nunca abandona el autenticador, ya que esto no es obligatorio. Si el usuario desea agregar otro autenticador, simplemente lo registra, genera un nuevo par de claves e identificador, y transfiere la clave pública con el identificador al sitio. Durante la autenticación, el sitio traduce el identificador al autenticador, y el autenticador encuentra el par de claves con él y firma la llamada.
¿Cómo se relacionará el nuevo estándar con los requisitos de las leyes de protección de datos (por ejemplo, GDPR)?
Nuestros principios son muy consistentes con GDPR. Incluso en el modo de dos factores, hacemos que la autenticación de phishing sea segura. Si hablamos de autenticación sin contraseña, entonces aquí no se transmiten contraseñas. Además, a diferencia de los certificados de cliente, nuestro protocolo no puede usarse como super cookies. Por lo tanto, muchas empresas ya están trabajando en la implementación de nuestros protocolos.
¿Y quién ya está implementando el estándar?
Google, Facebook, Dropbox, Salesforce, Bank of America, NTT Docomo ... Tenemos cientos de empresas y medio billón de usuarios diarios. Estamos creciendo todos los días. Pero aún así, cambiar a la autenticación sin contraseña completa llevará algún tiempo.
¿Qué tan rápido permite el estándar la transición desde otro método de autenticación?
Cambiar de soluciones de autenticación de dos factores existentes (por ejemplo, de OTP) a FIDO es bastante simple. Solo necesita conectar la biblioteca e implementar un par de cambios en el lado del cliente. En FIDO2, la opción de autenticación sin contraseña es solo un indicador adicional durante el registro. La transferencia de todo el ecosistema a la autenticación sin contraseña completa llevará algún tiempo. Prevemos que en 10 años esta transición completará el 80% de todos los servicios.
¿Cuáles son los planes de FIDO para desarrollar el estándar? ¿Qué mejoras se planean realizar en el futuro cercano? ¿Y a la larga?
Hasta ahora, nos hemos centrado en promover estándares. Hay millones de sitios en el mundo, esto significa que tenemos un millón de cosas que hacer. A la larga, planeamos trabajar en la implementación de estándares para Internet de las cosas para aumentar la seguridad de los dispositivos IoT. Los planes también incluyen el trabajo en sistemas de autenticación de estado, eID, pasaportes y sistemas de identificación descentralizados.
¿Cómo planea continuar trabajando en WebAuthn? ¿Cómo puede ayudarlo la comunidad de TI?
Yo, como antes, continúo mi trabajo como embajador en la comunidad de desarrolladores: publico artículos, trabajo en código abierto, hago presentaciones y realizo capacitaciones. En cuanto a la ayuda comunitaria, solo puedo decir: "Necesitamos más oro de código abierto".
PS Yuri Akkermann también preparó un artículo sobre Habré, en el que describió los principales mecanismos de seguridad de FIDO2 y revisó la API de JS para trabajar con él.