Desafío, autenticación y clave de sesión

Su protocolo está bastante subespecificado, pero aún se pueden hacer algunos comentarios:

• En el primer paso, el cliente elige aleatoriamente la "sal" y la envía junto con el valor hash, en cuyo caso este paso parece completamente inútil; o la sal es no enviada por el cliente, pero es un valor secreto previamente compartido entre el cliente y el servidor, en cuyo caso no es una sal sino una clave , y el resto del protocolo es completamente inútil.

• En el segundo paso, el cliente envía su nombre de usuario y "contraseña de hash" donde el hash usa algo de sal. Si el cliente siempre envía el mismo valor hash, la presentación de ese valor hash otorga acceso: es equivalente a la contraseña . Cualquier atacante que observe una conexión (puramente pasivamente) aprende lo suficiente como para falsificar la autenticación, por lo que el protocolo sería completamente débil.

Si su protocolo tiene que tener algún valor, debemos asumir que las cosas siguen así:

• El cliente se conecta; el servidor envía un valor aleatorio N (el término técnico es nonce ).
• El cliente envía otro valor aleatorio N ' al servidor (y también envía un valor de hash calculado sobre los valores públicos N y N' ; ese valor hash no sirve para ningún propósito útil).
• El cliente envía el nombre de usuario L y el valor h (N + N ', P) donde N y N' no se intercambian, P es la contraseña del usuario y h es una "función hash" que de alguna manera combina N y P (hay muchos métodos para hacer esta combinación, muchos de los cuales son débiles en formas más o menos sutiles).
• El servidor tiene una copia de P y, por lo tanto, puede volver a calcular el valor h (N + N ', P) y ver si coincide con lo que envió el cliente.
• El cliente y el servidor usan otra función h ' para calcular h' (N, P) y usan ese valor como una clave compartida para realizar un cifrado simétrico para el resto de los datos.

Suponiendo que hizo todo correctamente y usó las funciones hash de manera adecuada y no se olvidó de agregar controles de integridad y se ocupó de los millones de detalles de implementación que pueden afectar a los protocolos mejor diseñados, entonces habrá obtenido, en el mejor de los casos , TLS-PSK . Hay dos debilidades inherentes e inevitables en ese protocolo:

• El servidor debe almacenar un secreto de contraseña equivalente. Si un atacante obtiene una vista de solo lectura de los datos del servidor (una consecuencia habitual de los ataques de inyección de SQL o las copias de seguridad robadas), entonces aprende lo suficiente como para autenticarse como cualquiera de los usuarios registrados. Esto se considera malo. Consulte esta publicación de blog para una discusión sobre ese tema.

• Un atacante pasivo aprende lo suficiente como para ejecutar un ataque de diccionario sin conexión : el atacante solo tiene que observar una autenticación , y luego puede "probar contraseñas" en sus propias máquinas; simplemente enumera las contraseñas posibles hasta que encuentra una que coincida con los valores de hash que observó. Esto, una vez más, es malo, porque las contraseñas tienden a ser vulnerables a una búsqueda tan exhaustiva. Los ataques del diccionario en línea , donde el atacante debe hablar con el servidor genuino o el cliente genuino para cada intento de contraseña, son mucho menos preocupantes, ya que el servidor puede imponer limitaciones estrictas en el número de intentos por segundo; mientras que un ataque sin conexión está limitado solo por el poder computacional que el atacante puede reunir.

La forma correcta de realizar una autenticación mutua basada en contraseña cliente-servidor es utilizar un acuerdo de clave autenticado por contraseña , que resulta en un secreto compartido adecuado para el cifrado simétrico con controles de integridad. Básicamente, esto significa TLS-SRP . 15 años de implementaciones, ataques y correcciones han demostrado que el diseño e implementación de un protocolo seguro de ese tipo no es nada fácil.