Las contraseñas son un problema por razones que ignoran la mayoría de las personas que las usan. Si pierdes el control de tu contraseña, la seguridad quedará expuesta con total seguridad, sin importar su complejidad o lo difícil que sea de adivinar.
La mayoría de los lectores admitirán de inmediato las dificultades para recordar y administrar contraseñas, sobre todo porque los requisitos de estas son cada vez más complejos. Afortunadamente, existen grandes paquetes de software y complementos para el navegador que ayudan a administrarlas. Sin embargo, muchos os sorprenderéis al saber que los problemas, que son consecuencia de la falta de seguridad inherente de las contraseñas, son mucho más graves de lo que generalmente se cree.
Podrías decirnos: "¡Pero las contraseñas siempre se almacenan en formato encriptado!" y no te equivocas, pero es una afirmación incompleta. La verdad es que incluso una contraseña encriptada puede descifrarse, aunque (por suerte) no sin dificultades cuando se cifran correctamente. Un problema cada vez más acuciante radica en la naturaleza de las propias contraseñas: para utilizar una contraseña, directamente, esta debe administrarse sin cifrar.
"¡Pero mi contraseña se transmite de forma segura mediante HTTPS!". Es cierto.
"¡Sé que el servidor almacena mi contraseña en forma encriptada, segura, para que nadie pueda acceder a ella!", podrías asegurar. Bueno, en este caso estás depositando mucha confianza en el servidor. Aun así, digamos que sí, es verdad.
Sin embargo, queda una limitación: la brecha en el uso de las contraseñas de extremo a extremo. Ten en cuenta que una vez que un servidor recibe una contraseña, esta tiene que leerse y procesarse mientras se transmite y procesa de forma segura. Sí, ¡como texto sin formato!
Y lo que es peor, muchos están acostumbrados a pensar en software, lo que hace que sea más fácil olvidarse de la vulnerabilidad del hardware. Esto significa que, aunque el software sea de alguna manera de confianza, la contraseña debe en algún momento residir en la memoria. La contraseña se debe transmitir en algún momento a la CPU a través de un bus de datos compartido. Este proceso proporciona vectores de ataque a los observadores de muchas formas. No hay duda de que estos vectores de ataque son menos probables que los que presentan la transmisión y el almacenamiento permanente, pero no son menos graves (vulnerabilidades recientes de la CPU como Spectre y Meltdown deberían servir como un claro recordatorio).
La única forma de solucionar este problema es eliminar las contraseñas por completo. ¡Hay esperanza! Las comunidades de investigación y del sector privado están trabajando duro para lograrlo. Están surgiendo nuevos estándares que están avanzando. Lamentablemente, las contraseñas son tan ubicuas que va a llevar mucho tiempo alcanzar un acuerdo y sustituirlas por nuevos estándares y tecnología.
En Cloudflare, nos hemos preguntado si hay algo que podamos hacer ahora, de forma inminente. El análisis exhaustivo sobre OPAQUE que abordamos hoy es una posible respuesta. OPAQUE es uno de los muchos ejemplos de sistemas que permiten que una contraseña sea útil sin que pierdas el poder sobre ella. A nadie le gustan las contraseñas, pero mientras se usen al menos podemos asegurarnos de que nunca se revelen.
Soy la primera en admitir que las contraseñas son molestas: son difíciles de recordar, tediosas de escribir y bastante poco seguras. Las iniciativas para reducir o reemplazar las contraseñas son prometedoras. Por ejemplo, WebAuthn es un estándar de autenticación web basado principalmente en criptografía de clave pública que utiliza tokens de hardware (o de software). Aun así, y por muy frustrante que sea, las contraseñas siguen siendo el mecanismo de autenticación por excelencia. El hecho de que no podamos librarnos de ellas puede obedecer a su facilidad de implementación, a la confianza que ofrecen a los usuarios o su ubicuidad. Sea cual sea el motivo, nuestra meta es que la autenticación por contraseñas sea lo más segura posible mientras se siga empleando este método.
Mi trabajo como becaria en Cloudflare se centró en OPAQUE, un protocolo criptográfico que resuelve uno de los problemas de seguridad más evidentes de la autenticación por contraseña en la web: aunque están protegidas en tránsito por el protocolo HTTPS, los servidores las gestionan en texto sin formato para verificar su exactitud. La utilización de contraseñas de texto sin formato es peligrosa, ya que registrarlas accidentalmente o almacenarlas en caché podría provocar un fallo de seguridad catastrófico. El objetivo del proyecto, más que abogar por la adopción de un protocolo en particular, es demostrar que OPAQUE es una opción viable entre muchas otras para la autenticación. Debido a que el entorno web me es más familiar, y probablemente lo sea para muchos lectores, usaré la web como ejemplo principal.
Autenticación web 101: Contraseña mediante protocolo TLS
¿Qué ocurre cuando escribes una contraseña en la web? El sitio web tiene que verificar que la contraseña que escribiste sea la misma que la que utilizaste originalmente en el sitio. Pero, ¿cómo funciona esta comprobación?
Por lo general, tu nombre de usuario y contraseña se envían a un servidor. El servidor comprueba a continuación si la contraseña que tiene registrada para tu nombre de usuario coincide con la contraseña que facilitaste. No cabe duda de que para evitar que un atacante intercepte tu contraseña mientras navegas por Internet, tu conexión al servidor debe estar encriptada a través de HTTPS (HTTP mediante TLS).
A pesar del uso del protocolo HTTPS, sigue habiendo un problema evidente en esta dinámica: el servidor debe almacenar una representación de su contraseña en algún lugar. Los servidores son difíciles de proteger y los fallos de seguridad son demasiado habituales. La filtración de esta representación puede causar graves problemas de seguridad. (Puedes consultar los últimos fallos de seguridad en el siguiente enlace: https://haveibeenpwned.com/).
Para que estas filtraciones sean menos devastadoras, los servidores suelen aplicar una función hash a las contraseñas de los usuarios. Una función hash asigna cada contraseña a un valor de aspecto aleatorio único. Es fácil aplicar el hash a una contraseña, pero es casi imposible revertir la función y recuperar la contraseña. (Dicho esto, cualquiera puede adivinar una contraseña, aplicar la función hash y comprobar si el resultado es el mismo).
Con el hash aplicado a contraseñas, las contraseñas de texto sin formato ya no se almacenan en los servidores. Un atacante que roba una base de datos de contraseñas ya no tiene acceso instantáneo a las mismas. En cambio, el atacante necesita aplicar el hash a muchas contraseñas posibles y comparar los resultados con los hashes robados.
Por desgracia, si solo aplicamos el hash a las contraseñas, los atacantes pueden descargar tablas rainbow, o tablas arco iris precalculadas, que contienen hash de billones de posibles contraseñas y recuperar casi instantáneamente las contraseñas de texto sin formato. (Consulta https://project-rainbowcrack.com/table.htm para obtener una lista de algunas tablas rainbow).
Teniendo esto en cuenta, una buena y exhaustiva estrategia de defensa es añadir un salt al hash, donde el salt es un valor aleatorio que se añade a la contraseña, siendo el servidor quien encripta la contraseña y el salt. El servidor también guarda el salt al lado del nombre de usuario, por lo que el usuario ni lo ve ni necesita enviarlo. Cuando el usuario envía una contraseña, el servidor vuelve a calcular esta función hash utilizando el salt. Por tanto, un atacante que roba datos de contraseñas, es decir, las representaciones de contraseñas y los valores salt, tiene que descifrar una por una las contraseñas comunes y aplicar la función a cada una de ellas. Las tablas rainbow existentes no le servirán de ayuda porque no tienen en cuenta los valores salt, por lo que el atacante debe crear una nueva tabla rainbow ¡para cada usuario!
Esto (con suerte) ralentiza el ataque lo suficiente como para que el servicio informe a los usuarios del fallo de seguridad, de modo que puedan cambiar sus contraseñas. Además, la efectividad de los hashes con salt se puede reforzar aplicando un hash muchas veces para ralentizar los ataques. (Consulta https://blog.cloudflare.com/keeping-passwords-safe-by-staying-up-to-date/ para obtener más información).
Estas dos estrategias de mitigación, el cifrado de la contraseña en tránsito y el almacenamiento de hashes reforzados con salt, son las mejores prácticas de hoy en día.
Un gran brecha de seguridad sigue abierta. Una contraseña mediante protocolo TLS (como lo llamaremos) requiere que envíes tu contraseña de texto sin formato al servidor cada vez que inicias sesión porque el servidor debe ver tu contraseña para verificarla con las contraseñas registradas. Incluso un servidor bien intencionado podría almacenar accidentalmente la información en caché o registrar tu intento o intentos de acceso con la contraseña, o dañarse en el curso de la verificación de esta. (Por ejemplo, Facebook se dio cuenta en 2019 de que había estado almacenando sin querer millones de contraseñas de texto sin formato de sus usuarios). En teoría, los servidores nunca deberían ver una contraseña de texto sin formato.
Pero esto es como una encrucijada: ¿cómo puedes verificar una contraseña si no la ves? Con OPAQUE, un protocolo de intercambio de claves autenticadas por contraseña (PAKE) que acredita conocer una contraseña y deriva una clave secreta simultáneamente. Antes de describir OPAQUE en detalle, primero resumiremos las funcionalidades de PAKE en general.
Pruebas de contraseña con intercambio de claves autenticadas con contraseña
El intercambio de claves autenticadas por contraseña (PAKE) fue propuesto por Bellovin y Merrit[1] en 1992, con el objetivo inicial de permitir la autenticación de contraseñas sin la posibilidad de ataques de diccionario basados en datos transmitidos a través de un canal inseguro.
Básicamente, el PAKE, plano o simétrico, es un protocolo criptográfico que permite a dos partes que comparten solo una contraseña establecer una clave secreta compartida y segura. Los objetivos del PAKE son:
1) Las claves secretas coincidirán si las contraseñas coinciden y, en caso contrario, serán aleatorias.
2) Los participantes no necesitan confiar en terceros (particularmente, en ninguna infraestructura de clave pública).
3) La clave secreta resultante no la conoce nadie ajeno al protocolo, ni siquiera aquellos que conocen la contraseña.
4) El protocolo no revela la contraseña de ninguna de las partes al otro (a menos que las contraseñas coincidan) ni tampoco a los intrusos.
En resumen, la única forma de atacar con éxito el protocolo es adivinar la contraseña correctamente mientras se participa en el protocolo. (Afortunadamente, estos ataques se pueden neutralizar en su mayoría mediante rate-limiting, es decir, impidiendo que un usuario inicie sesión después de un cierto número de intentos de contraseña incorrectos).
A partir de estos requisitos, se entiende que la contraseña mediante protocolo TLS claramente no es un PAKE, porque:
- Depende de WebPKI, que confía en terceras partes denominadas Autoridades de certificación (consulta https://blog.cloudflare.com/introducing-certificate-transparency-and-nimbus/ para saber más sobre WebPKI y algunas de sus limitaciones).
- La contraseña del usuario se revela al servidor.
- La contraseña mediante el protocolo TLS no proporciona al usuario ninguna garantía de que el servidor conozca su contraseña o un derivado de ella: un servidor podría aceptar cualquier dato del usuario sin ningún tipo de verificación.
Dicho esto, las prestaciones de seguridad del PAKE plano son inferiores a las de la contraseña mediante protocolo TLS, simplemente porque requiere que el servidor almacene contraseñas en texto sin formato. Necesitamos un PAKE que permita al servidor almacenar hashes con salt si queremos superar la práctica actual.
La mejora con respecto al PAKE plano es lo que se conoce como PAKE asimétrico (aPAKE) porque solo el cliente conoce la contraseña y el servidor conoce un hash de contraseña. Un aPAKE tiene además de las cuatro propiedades de un PAKE, una más:
5) Un atacante que roba datos de contraseña almacenados en el servidor debe realizar un ataque de diccionario para recuperar la contraseña.
Sin embargo, el problema con la mayoría de los protocolos aPAKE existentes es que no permiten un hash con salt (o si lo hacen, requieren que el salt se transmita al usuario, lo que significa que el atacante tiene acceso al salt de antemano y puede comenzar calcular una tabla rainbow para el usuario antes de robar cualquier dato). Por lo tanto, nos gustaría actualizar la propiedad de seguridad de la siguiente manera:
5*) Un atacante que roba datos de contraseña almacenados en el servidor debe realizar un ataque de diccionario por usuario para recuperar la contraseña después de que los datos se vean comprometidos.
OPAQUE es el primer protocolo aPAKE con prueba formal de seguridad que tiene esta propiedad: permite un salt completamente secreto.
OPAQUE - Los servidores protegen las contraseñas ¡sin conocerlas!
OPAQUE es lo que se conoce como un aPAKE sólido, que significa simplemente que resiste estos ataques precalculados usando un hash con salt secreto en el servidor. Stanislaw Jarecki, Hugo Krawcyzk y Jiayu Xu propusieron y analizaron oficialmente OPAQUE en 2018 (dato revelador: Stanislaw Jarecki es mi mentor académico). El nombre OPAQUE es una combinación de los nombres de dos protocolos criptográficos: OPRF y PAKE. Ya conocemos PAKE, pero ¿qué es OPRF? OPRF son las siglas de Oblivious Pseudo-Random Function, en español, función pseudoaletoria ajena, que es un protocolo mediante el cual dos partes calculan una función F (clave, x) que es determinista, pero que genera valores de apariencia aleatoria. Una parte introduce el valor x y la otra introduce la clave: la parte que inserta x descubre el resultado F (clave, x), pero no la clave, y la parte que proporciona la clave no descubre nada. (Para obtener más información sobre el funcionamiento matemático de OPRF visita: https://blog.cloudflare.com/privacy-pass-the-math/).
En esencia, OPAQUE es un método de almacenaje de información confidencial de un usuario en un servidor, sin que este tenga acceso a dicha información. En lugar de almacenar un hash de contraseña tradicional con salt, el servidor almacena un sobre secreto para ti que está "bloqueado" por dos datos: tu contraseña, que solo conoces tú, y una clave secreta aleatoria (como un salt), que solo conoce el servidor. Para iniciar sesión, el cliente inicia un intercambio criptográfico que revela la clave del sobre al cliente, pero, lo más importante es que no la releva al servidor.
Posteriormente, el servidor envía el sobre al usuario, quien ahora puede recuperar las claves cifradas. (Las claves incluidas en el sobre son un par de claves pública y privada para el usuario y una clave pública para el servidor). Estas claves, una vez desbloqueadas, serán las entradas a un protocolo de intercambio de claves autenticadas (AKE), que permiten al usuario y al servidor establecer una clave secreta que se puede utilizar para cifrar su comunicación futura.
OPAQUE consta de dos fases: registro de credenciales e inicio de sesión a través de intercambio de claves.
OPAQUE - Fase de registro
Antes del registro, el usuario se registra por primera vez en un servicio y elige un nombre de usuario y una contraseña. El registro comienza con el flujo OPRF que acabamos de describir: Alice (el usuario) y Bob (el servidor) hacen un intercambio OPRF. El resultado es que Alice tiene una contraseña aleatoria rwd, derivada de la salida OPRF F (clave, pwd), donde clave es una clave OPRF propiedad del servidor específica para Alice y pwd es la contraseña de Alice.
Dentro de su mensaje OPRF, Bob envía la clave pública de su identidad OPAQUE. Posteriormente, Alice genera un nuevo par de claves pública/privada, que serán su identidad OPAQUE permanente para el servicio de Bob, y encripta su clave secreta junto con la clave pública de Bob con la rwd (llamaremos al resultado un sobre cifrado). Alice envía este sobre cifrado junto con su clave pública (sin cifrar) a Bob, quien almacena los datos que ella le proporcionó, junto con su OPRF secreto, en una base de datos indexada por su nombre de usuario.
OPAQUE - Fase de inicio de sesión
La fase de inicio de sesión es muy similar. Comienza de la misma forma que el registro, con un flujo OPRF. Sin embargo, en la parte del servidor, Bob no genera una nueva clave OPRF, sino que busca la que creó en el registro de Alice. Para ello, busca el nombre de usuario de Alice (el que ella le proporcionó en el primer mensaje) y recupera el registro que generó de ella. Este registro contiene su clave pública, su sobre cifrado y la clave OPRF de Bob específicas para Alice.
También envía el sobre cifrado que Alice puede descifrar con la salida del flujo OPRF. (Si el descifrado falla, Alice interrumpe el protocolo; esto probablemente indica que escribió su contraseña de manera incorrecta o que Bob no es quien dice ser). Si logra el descifrado, ahora tiene su propia clave secreta y la clave pública de Bob. Alice las introduce en un protocolo AKE con Bob, quien también introduce su clave privada y su clave pública, lo que les da a ambos una clave secreta nueva.
Integración de OPAQUE con un protocolo AKE
Una pregunta importante que hay que hacerse es: ¿qué protocolo AKE es adecuado para OPAQUE? La nueva especificación del CFRG esboza varias opciones, incluidos los protocolos 3DH y SIGMA-I. Sin embargo, en la web, ya tenemos un AKE a nuestra disposición: ¡TLS!
Recordemos que TLS es un AKE porque provee autenticación unilateral (y mutua) con derivación de clave compartida. En el centro de la cuestión de TLS radica un intercambio de claves Diffie-Hellman, que en sí mismo no está autenticado, lo que significa que las partes que lo ejecutan no tienen forma de verificar con quién lo están ejecutando. (Esto es un problema porque cuando inicias sesión en tu banco, o en cualquier otro sitio web que almacena tus datos privados, quieres estar seguro de que la entidad con la que te comunicas es quien dice ser). La autenticación utiliza principalmente certificados, que son emitidos por entidades de confianza a través de un sistema denominado infraestructura de clave pública (PKI). Cada certificado está asociado con una clave secreta. Para probar su identidad, el servidor presenta su certificado al cliente y firma el protocolo de enlace TLS con su clave secreta.
La modificación de esta autenticación por certificados en la web tal vez no sea el mejor punto de partida. En cambio, una mejora sería autenticar el secreto compartido del TLS, a través de OPAQUE, una vez se complete el protocolo de enlace TLS. En otras palabras, una vez que un servidor se autentica con su certificado típico WebPKI, los clientes podrían autenticarse posteriormente en el servidor. Esta autenticación podría tener lugar "después del protocolo de enlace" en la conexión TLS con OPAQUE.
Los autenticadores exportados son un mecanismo de autenticación "tras el protocolo de enlace" en TLS. Permiten que un servidor o cliente presente una prueba de una nueva identidad sin configurar una nueva conexión TLS. Recordemos que en el caso de una web estándar, el servidor establece su identidad con un certificado (acreditando, por ejemplo, que es “cloudflare.com”). Pero, si el mismo servidor también tiene identidades alternativas, deben ejecutar el protocolo TLS nuevamente para demostrar quiénes son.
El funcionamiento del flujo básico del autenticador exportado es similar a un protocolo clásico de desafío-respuesta, y es el siguiente: (Consideraremos el caso de autenticación del servidor, ya que el caso del cliente es simétrico)
En cualquier momento después de que se establece una conexión TLS, Alice (el cliente) envía una solicitud de autenticación para indicar que le gustaría que Bob (el servidor) demuestre una identidad adicional. Esta solicitud incluye un contexto (una cadena impredecible; piensa en esto como un desafío) y extensiones que incluyen información sobre la identidad que el cliente desea que se le proporcione. Por ejemplo, el cliente podría incluir la extensión SNI para solicitar al servidor un certificado asociado con un determinado nombre de dominio que no sea el que se usó inicialmente en la conexión TLS.
Al recibir el mensaje del cliente, si el servidor tiene un certificado válido correspondiente a la solicitud, envía un autenticador exportado que prueba que tiene la clave secreta para el certificado. (Este mensaje tiene el mismo formato que un mensaje de autenticación del cliente en el protocolo de enlace TLS 1.3 y contiene los siguientes mensajes: Certificate, CertificateVerify y Finished). Si el servidor no puede o no desea autenticarse con el certificado solicitado, responde con un autenticador vacío que contiene solo el mensaje Finished bien formado.
Acto seguido, el cliente verifica que el autenticador exportado que recibe esté bien formado y después verifica que el certificado presentado sea válido y, de ser así, acepta la nueva identidad.
Recapitulemos. Los autenticadores exportados son una forma de realizar la autenticación en una capa superior (como la capa de aplicación) de manera segura al aprovechar la criptografía y los formatos de los mensajes aprobados de TLS. Además, están vinculados a la sesión TLS para que los mensajes de autenticación no se puedan copiar y pegar de una conexión TLS a otra. En otras palabras, los autenticadores exportados facilitan exactamente los instrumentos correctos necesarios para agregar la autenticación basada en OPAQUE en TLS.
OPAQUE con autenticadores exportados (OPAQUE-EA)
OPAQUE-EA permite que OPAQUE se ejecute en cualquier punto después de que ya se haya configurado una conexión TLS. Recuerda que Bob (el servidor) almacenará su identidad OPAQUE, en este caso una clave de firma y una clave de verificación, y Alice almacenará su identidad, cifrada, en el servidor de Bob. (El flujo de registro donde Alice almacena sus claves encriptadas es el mismo que hemos visto en OPAQUE, excepto que Alice almacena una clave de firma, así que saltaremos directamente al inicio de sesión). Alice y Bob ejecutan dos flujos EA de solicitud de autenticación, uno para cada parte, y los mensajes del protocolo OPAQUE van en la sección de extensiones de los EA. Profundicemos en su funcionamiento.
En primer lugar, Alice genera su mensaje OPRF en función de su contraseña. Crea una solicitud de autenticador solicitando la identidad OPAQUE de Bob, e incluye (en el campo de extensiones), su nombre de usuario y su mensaje OPRF, que envía a Bob a través de su conexión TLS establecida.
Bob recibe el mensaje y busca el nombre de usuario de Alice en su base de datos. Acto seguido, recupera el registro OPAQUE de Alice que contiene su clave de verificación y sobre cifrado, así como su clave OPRF. Bob utiliza la clave OPRF en el mensaje OPRF y crea un autenticador exportado que demuestra la propiedad de su clave de firma OPAQUE, con una extensión que contiene su mensaje OPRF y el sobre cifrado. Además, envía una nueva solicitud de autenticador pidiéndole a Alice que demuestre la propiedad de su clave de firma OPAQUE.
Alice analiza el mensaje y completa la evaluación del OPRF usando el mensaje de Bob para obtener la salida rwd, y usa la clave rwd para descifrar el sobre. Así revela su clave de firma y la clave pública de Bob. Alice usa la clave pública de Bob para verificar su prueba de respuesta del autenticador y, si es correcta, crea y envía un autenticador exportado que prueba que tiene la clave de firma recién descifrada. Bob comprueba la validez de su autenticador exportado y, si todo está correcto, acepta el inicio de sesión de Alice.
Mi proyecto: OPAQUE-EA mediante HTTPS
Todo lo descrito anteriormente encuentra su fundamento en abundante teoría que aún no se ha reflejado en la práctica. Mi proyecto consistía en convertir la teoría en realidad. Comencé con descripciones escritas de autenticadores exportados, OPAQUE y un borrador preliminar de OPAQUE-in-TLS. A partir de ese punto, mi objetivo era crear un prototipo funcional.
Mi demo muestra la viabilidad de implementar OPAQUE-EA en la web, eliminando completamente tanto las contraseñas de texto sin formato de Internet, como las encriptadas. Esto proporciona una posible alternativa al flujo actual de contraseña mediante protocolo TLS con mejores propiedades de seguridad, pero sin cambios visibles para el usuario.
Vale la pena conocer algunos de los detalles de la implementación. En ciencias de la computación, la abstracción es una herramienta poderosa. Significa que a menudo podemos confiar en las herramientas existentes y en las API para evitar duplicar esfuerzos. En mi proyecto confié en gran medida en mint, una aplicación de código abierto de TLS 1.3 en Go que es excelente para la creación de prototipos. También recurrí a la biblioteca CIRCL para OPRF. Creé bibliotecas para autenticadores exportados, fundamento esencial de OPAQUE y OPAQUE-EA (que une a los dos).
Elaboré la web demo envolviendo la funcionalidad OPAQUE-EA en un servidor HTTP simple y un cliente que se pasan mensajes entre sí a través de HTTPS. Como un navegador no puede ejecutar Go, utilicé un compilador de Go a WebAssembly (WASM) para obtener la funcionalidad Go en el navegador y escribí un script simple en JavaScript para solicitar las funciones WASM que necesitaba.
Dado que los navegadores actuales no dan acceso a la conexión TLS subyacente en el lado del cliente, implementé un comando para permitir que el cliente acceda a las claves del exportador, es decir, que el servidor simplemente calcula las claves y las envía al cliente a través de HTTPS. Esta solución reduce la seguridad de la demo resultante, lo que significa que confía en el servidor para proporcionar las claves correctas. Aun así, incluso si un servidor malicioso proporcionó claves incorrectas, la contraseña del usuario sigue siendo segura, simplemente no tiene la seguridad de que se haya registrado previamente en el servidor. Sin embargo, en el futuro, los navegadores podrían incluir un mecanismo para admitir claves exportadas y permitir que OPAQUE-EA se ejecute con todas sus propiedades de seguridad.
Puedes explorar mi aplicación en Github e incluso seguir las instrucciones para poner en marcha tu propio cliente y servidor de prueba OPAQUE-EA. Sin embargo, me gustaría hacer hincapié en que la aplicación está pensada solo como una prueba de concepto y no debe usarse para sistemas de producción sin una revisión adicional significativa.
Limitaciones de OPAQUE-EA
A pesar de sus excelentes propiedades, definitivamente habrá algunos obstáculos para hacer que OPAQUE-EA pase de ser una prueba de concepto a un mecanismo de autenticación totalmente desarrollado.
Compatibilidad del navegador para claves de exportador TLS. Como ya se ha mencionado brevemente, para ejecutar OPAQUE-EA en un navegador, tienes que acceder a los secretos de la conexión TLS denominados claves de exportador. No hay forma de hacer esto en los navegadores más populares actuales, por lo que será necesario trabajar en la compatibilidad para utilizar esta función.
Renovación de las bases de datos de contraseñas. Para adoptar OPAQUE-EA, los servidores no solo necesitan actualizar su lógica de verificación de contraseñas, sino también renovar completamente sus bases de datos de contraseñas. Debido a que OPAQUE se basa en representaciones de contraseñas especiales que solo se pueden generar de forma interactiva, las contraseñas hash con salt existentes no se pueden actualizar automáticamente a registros OPAQUE. Es probable que los servidores necesiten ejecutar un flujo de registro OPAQUE especial para cada usuario. Debido a que OPAQUE depende de la aceptación tanto del cliente como del servidor, es posible que los servidores deban mantener el método anterior durante un tiempo antes de que todos los clientes se pongan al día.
Confianza en nuevos estándares. OPAQUE-EA se basa en el protocolo OPRF, que está en proceso de estandarización, y en autenticadores exportados, que es un estándar propuesto. Esto significa que la compatibilidad con estas dependencias aún no está disponible en la mayoría de las bibliotecas criptográficas existentes, por lo que es posible que los primeros usuarios necesiten implementar estas herramientas ellos mismos.
Resumen
Siempre que las personas sigan usando contraseñas, nos gustaría que el proceso fuera lo más seguro posible. Los métodos actuales se basan en la práctica arriesgada de administrar contraseñas de texto sin formato en el servidor mientras se verifica su exactitud. Los PAKE y (específicamente los aPAKE) permiten el inicio de sesión seguro con contraseña impidiendo que el servidor vea las contraseñas. OPAQUE es uno de los mejores aPAKE que existen y se puede integrar completamente en TLS. Puedes consultar el código aqui.
[1] Bellovin, S. M., and Merritt, M. “Encrypted key exchange: Password-based protocols secure against dictionary attacks.” Proc. IEEE Computer Society Symposium on Research in Security and Privacy (Oakland, May 1992), 72–84.