Para iniciar un intercambio de claves utilizando el protocolo SRP el cliente envía el nombre de usuario para que el servidor pueda buscar el Verificador de sal y contraseña. ¿Hay una forma sencilla de cambiar esto para que un evesdropper no pueda descubrir el nombre de usuario?
Creo que un Diffie-Hellman adicional podría encargarse de eso, pero el protocolo SRP es tan similar que me pregunto si hay una manera de fusionar eso sin mucha sobrecarga.
Diffie-Hellman no ayudaría aquí: un atacante activo podría usar un MITM clásico MITM y ver los datos que se supone que están protegidos por la clave DH. Solo vería el intercambio de SRP "desde el exterior", pero aún así aprendería el nombre de usuario.
El no anonimato del usuario que se conecta es una propiedad fundamental de los algoritmos de Password-Authenticated Key Exchange . Dichos protocolos se resisten a los ataques de diccionario sin conexión porque ambas partes hacen compromisos específicos de contraseña en las primeras etapas del protocolo.
En SRP, el servidor debe elegir un b aleatorio, y enviar B = v + g b al cliente. Un servidor falso no sabe v pero le gustaría aprenderlo, porque saber v permite un ataque de diccionario sin conexión (es decir, "intentar" contraseñas hasta que una coincida, en el la propia computadora del atacante, sin interactuar más con el usuario o el servidor real). Sin embargo, debido a la dificultad del logaritmo discreto, un atacante no puede saber tanto v como b que coinciden con un B dado, a menos que elija < em> v y b y calculamos B a partir de esos valores. El atacante no puede mirar atrás a su mensaje pasado y pensar cosas como: "bueno, supongamos que en lugar del v que usé, debería haber usado v ' porque eso es lo que el cliente pudo haber entendido "; si lo hace, entonces pierde el conocimiento de b , y sin el conocimiento de b está "fuera" del intercambio Diffie-Hellman posterior (SRP es, en su esencia, , un Diffie-Hellman con campanas encendidas). De esa manera, B es un compromiso: el servidor confirma a un valor determinado dependiente de la contraseña v cuando envía B , porque no podrá obtener ninguna información útil del resto del protocolo a menos que siga usando ese valor exacto de v . Esto es donde ocurre la magia de PAKE: este compromiso garantiza que un atacante debe interactuar con el usuario o el servidor real o con ambos para la contraseña cada que está adivinando. Esto reduce considerablemente la eficiencia de los ataques de diccionario, y ese es el punto de los protocolos PAKE.
Dado que el servidor debe comprometerse con un valor determinado que depende de la contraseña al comienzo del protocolo ( antes la autenticación realmente se ha producido), el servidor debe saber de qué contraseña estamos hablando, por lo tanto, una identificador de usuario enviado "en claro".
Para preservar el anonimato del usuario con respecto a los escuchas ilegales, el servidor primero debe ser autenticado por el cliente de manera independiente, que es lo que se obtiene de un TLS túnel con certificados de servidor, pero si usa SRP, ¿no es precisamente para evitar el uso de certificados? Además, en una configuración relacionada con Internet, el intruso seguirá aprendiendo la dirección IP del usuario, que en muchos casos es casi tan bueno como un nombre.
Si solo quiere defenderse contra un intruso pasivo, entonces hay una manera simple: configurar una conexión cifrada entre el cliente y el servidor, y luego enviar todos los mensajes SRP a través de esta conexión cifrada.
En la práctica, un enfoque pragmático sería configurar una conexión SSL o una VPN entre el cliente y el servidor, y enviar todo a través de este túnel cifrado. Si el cliente no revisa el certificado del servidor, entonces esto es seguro contra escuchas pasivas pero no contra un atacante activo (un hombre en el medio).
Si el cliente comprueba el certificado del servidor, esto también será seguro contra los atacantes activos y los ataques MITM (hasta la capacidad del cliente para verificar el certificado del servidor).
Siempre puede proteger el contenido (incluso las credenciales de inicio de sesión) mediante el cifrado, generalmente el cifrado de transporte, como SSL.
En general, es una mala idea enrollar su propia base criptográfica utilizando DH o algo similar; el uso de algo establecido (de nuevo, como SSL) lo ayuda a protegerse contra los errores que podría no haber anticipado. Por ejemplo, el problema de realizar un cifrado simétrico con una clave generada por DH es que se trata de un cifrado sin autenticación. El cliente tiene una conexión segura con alguien , pero no sabe si esa persona es el servidor o si es un atacante MITM. La autenticación basada en certificados en SSL protege contra esa posibilidad.
Por lo tanto, establezca una conexión cifrada del cliente al servidor, utilizando un certificado firmado públicamente para uso general o genere su propio certificado de firma si su aplicación es el único cliente. Luego, una vez que se establezca el enlace cifrado, ENTONCES envíe sus credenciales de inicio de sesión, etc. Y también podría GUARDAR la conexión cifrada después de eso, ya que la sobrecarga es mínima y la seguridad incrementada es significativa.
Lea otras preguntas en las etiquetas passwords authentication cryptography encryption key-exchange