Un protocolo para autenticar usuarios sin nombre de usuario / contraseña

3

A intercambio casual de mensajes en reddit Ayer no me importó. podría ser posible diseñar un protocolo que elimine la necesidad de que los usuarios recuerden una contraseña única para cada uno de los servicios a los que se conecta.

La idea es que, en esencia, cada usuario proporciona credenciales de identificación (nombre, fecha de nacimiento, ciudad de nacimiento) y una contraseña secreta. Sobre la base de esta información y del servicio al que se accede (opcional, en caso de que el usuario no desee realizar un seguimiento entre los servicios), el software del cliente puede generar de manera determinista un par de llaves RSA (utilizando un esquema de hashing seguro, tal vez SHA-512). / p>

El componente público de este par de claves se pasa al servicio y sirve como un token de autenticación y una clave de cifrado. El usuario solo necesita recordar una contraseña y credenciales para acceder a cualquier servicio de cualquier cliente, con la clave pública como su identificación segura. Las claves específicas de sesión efímeras aún se pueden usar para el secreto de reenvío.

Me pregunto cuáles son los inconvenientes de este esquema. No es susceptible de suplantación de identidad a menos que el impostor se apodere de la clave privada, la falta de múltiples contraseñas lo hace más seguro y confiable para los usuarios. Es susceptible a MITM y a un cliente comprometido (porque ve la contraseña), pero es lo mismo que SSL hoy y la amenaza de los registradores de claves.

Por lo tanto, me pregunto si hay algún inconveniente grave que haya pasado por alto, y también si alguien quisiera experimentar con esto, ¿tendría sentido construir esto sobre TLS (una extensión de http, tal vez), o para reemplazarlo?

¡Gracias!

Editar :
Gracias Thomas Pornin por la respuesta bien razonada. Me pregunto si las siguientes son refutaciones válidas a las (objeciones fundadas) que usted planteó:

1. Dado que solo hay una contraseña en este esquema, no es irrazonable que exista un estricto requisito de complejidad (por ejemplo, al menos 128 bytes, etc.), por lo que no es susceptible de ataques de diccionario. Los ataques de diccionario son realmente lo mismo que decir que si el atacante tiene infinitos recursos a su disposición, puede forzar cualquier esquema. Mientras el esquema sea tal que no se pueda obtener información adivinando partes de la contraseña, entonces seguramente es posible hacer que los ataques de diccionario no sean prácticos.

  1. Respecto a la necesidad de cambiar la contraseña: esto no sería posible dentro del protocolo limitado descrito en la pregunta. ¿Tal vez al registrar la identidad pública de los usuarios, el servidor puede enviar un código secreto codificado con la clave de los usuarios que debe usarse solo para invalidar la identidad cuando sea necesario? Siempre que haya una clave pública por servicio (es decir, generada de forma determinista en función de una combinación incontenible de contraseña de usuario e identidad de servicio, un atacante solo puede comprometer el acceso a un servicio en particular).

Por cierto, ¿conoces algún algoritmo conocido para generar el par de claves basado solo en un (por ejemplo) número de 512 bits? Supongo que esto es lo mismo que preguntar si hay una manera de encontrar el primo seguro más cercano dado un número. Gracias!

    
pregunta Amit 27.07.2013 - 17:19
fuente

2 respuestas

5

Tu idea es doble:

  1. Utilice un par de claves asimétricas del lado del cliente para la autenticación.
  2. Genere la clave privada de forma determinista a partir de una contraseña.

La primera parte es un problema estándar en SSL; Consulte el estándar . Los navegadores web lo admiten (pero su GUI ha sido fea, confusa, o ambas cosas).

La segunda parte no es compatible con el software ampliamente implementado, pero no es nueva, y funciona con la siguiente advertencia: permite ataques de diccionario fuera de línea . De hecho, la clave pública del cliente es pública y se envía "tal cual" (dentro del certificado del cliente) a cualquier servidor SSL que la solicite. Además, por naturaleza, el servidor debe verlo en algún momento. Dado que la clave privada se genera de manera determinista a partir de la contraseña, un atacante puede "probar" las contraseñas en su propia máquina, buscando una coincidencia con la clave pública observada.

Esto es en realidad muy genérico . Considere un sistema y protocolo, donde tanto el cliente como el servidor están "abiertos": ninguno de ellos almacena ningún valor secreto, a los ojos del atacante: si el servidor puede almacenar secretos, la lista proverbial de contraseñas (con hash) en el La base de datos del servidor es suficiente. El único secreto en todo el sistema es la contraseña del usuario, que se almacena en la cabeza del usuario y es desconocida para el atacante. El atacante quiere recuperar esa contraseña.

En estas condiciones, para cualquier protocolo que pueda encontrar , es posible que se produzcan ataques de diccionario sin conexión. Eso es consustancial a la apertura de los sistemas: dado que se supone que el atacante sabe todo acerca de la configuración completa, excepto la contraseña del usuario, entonces puede emular todo en sus propias máquinas, para cada contraseña potencial : el atacante ejecuta el cliente y el servidor en un entorno virtual en su propio clúster.

Lanzar RSA y hash y eso no cambiará nada de eso. Una vez que los ataques de diccionario fuera de línea sean posibles, volverá a la solidez de la contraseña. Hay maneras para tratar de hacer frente a los ataques de diccionario sin conexión, pero la situación sigue siendo, en general, incómoda.

Para resistir los ataques de diccionario fuera de línea, debes tener un secreto en el cliente o en el servidor . En el servidor, este es el modelo habitual de contraseñas con hash en una base de datos que el servidor intenta proteger (con más o menos éxito); Las contraseñas no se almacenan "como están", sino que están en hash, como una segunda línea de defensa. En el cliente, simplemente almacene una clave privada asimétrica; posiblemente, cifrarlo localmente con una contraseña, como una segunda línea de defensa. Esto es compatible de forma inmediata con los navegadores existentes (bueno, al menos Firefox y su "contraseña maestra").

Aparte de las preocupaciones de seguridad sobre los ataques de diccionario, hay problemas prácticos con la generación de claves privadas deterministas a partir de la contraseña del usuario. En particular, ¿qué sucede cuando el usuario cambia su contraseña? Su par de llaves muta. Por lo tanto, todos los servidores con los que se utiliza la clave privada deben contactarse para confirmar la nueva clave pública para aceptar. Esto trae al baile el problema habitual de distribución de clave pública , luego PKI, los certificados y sus etiquetas. Esto tiene ramificaciones de largo alcance.

    
respondido por el Thomas Pornin 29.07.2013 - 15:06
fuente
2

Esto se denomina autenticación de certificado bidireccional o autenticación de certificado de cliente y ya ha sido compatible con SSL desde hace bastante tiempo. Simplemente no se usa demasiado en la naturaleza porque causa problemas con la administración de certificados al tratar con múltiples computadoras, lo que dificulta a los usuarios más que un simple nombre de usuario y contraseña.

Si desea ver cómo funciona, puede consultar StartSSL.com, que es una entidad de certificación que utiliza autenticación de certificados de doble vía, o fuera de un contexto web, TeamSpeak 3 también utiliza certificados de cliente para la autenticación. Así es como realiza un seguimiento de su usuario, pero nunca le pide un nombre de usuario y contraseña. Lo llaman identidad y proporcionan medios para moverlo, pero es simplemente un certificado de cliente.

Como solicitó específicamente inconvenientes, el principal es el uso de múltiples dispositivos y los problemas de administración clave que esto conlleva. Una forma de hacerlo es proporcionar contraseñas de uso único que permitan vincular otra computadora y realizar un seguimiento de las múltiples claves de clientes que corresponden al usuario. Sin asociar alguna descripción de usuario a cada uno, también es difícil eliminar el acceso de un dispositivo perdido.

Una implementación ideal podría almacenar un certificado público junto con una descripción de la computadora que se usa para cada inicio de sesión y luego permitir la generación de una clave única para que el usuario la use en otra computadora para vincularla a su cuenta general. Esto permitiría eliminar un dispositivo perdido al iniciar sesión en otro dispositivo para eliminar la cuenta. También se puede usar una contraseña (o algún otro medio de autenticación) para hacer la eliminación para evitar que el dispositivo perdido elimine los dispositivos legítimos.

Esto también se usa a menudo en combinación con contraseñas en entornos de mayor seguridad, ya que requiere algo que sepa (contraseña) y algo que tenga (certificado de cliente). Esto se conoce ampliamente como autenticación de dos factores, ya que requiere dos de los tres factores básicos: quién eres (biométrica), qué sabes (contraseña) y qué tienes (tokens, certificados, tarjetas, etc.).

    
respondido por el AJ Henderson 27.07.2013 - 18:48
fuente

Lea otras preguntas en las etiquetas