Fundamentos de la seguridad del protocolo basado en cadenas

Question

No estaba seguro de cómo formular esta pregunta, así que le pido disculpas de antemano si se trata de un duplicado de otra cosa.

Quería comprobar con cordura cómo he asegurado mi aplicación twisted based y creo que he hecho un buen trabajo en ella, pero hace más de una década que escribí todo lo que utiliza sockets sin procesar o administrados.

Transacción de autenticación: El cliente se conecta e inmediatamente se envía una respuesta de desafío con una cadena hexadecimal de 16 caracteres. El lado del cliente toma el nombre de usuario & contraseña, la contraseña se convierte sha1 (salt + sha1 (contraseña)) y las credenciales se envían al servidor como {nombre de usuario, contraseña}. En el lado del servidor, la autenticación hace un patrón de búsqueda estándar (si el usuario existe y tiene una contraseña igual a la entrada que otorgar).

Si se pierde la conexión entre el usuario & cliente, la clase de protocolo se marca a sí misma como sucia y se desconecta del objeto de usuario. En cualquier momento después de este punto, para acceder de nuevo al objeto del usuario, el cliente tendría que repetir el proceso de autenticación con una nueva sal.

¿Echo de menos algo? ¿Hay un enfoque mejor/más seguro para un protocolo basado en secuencias de caracteres?

Answer 1

El protocolo que describió trata un ataque, es decir, un ataque de repetición. Sin embargo, eres muy vulnerable a los ataques MITM. La conexión TCP no se reducirá cuando el atacante se mueva en el protocolo. Además, cualquier cosa transferida sobre este sistema puede ser olfateada. Si está conectado a la red inalámbrica en un café, todos en el área podrán oler todo lo que se transmite y luego MITM la sesión autenticada. Otro punto es que sha1() ha demostrado ser inseguro; debes usar sha256 para cualquier cosa relacionada con la seguridad.

NUNCA REINVENTES LA RUEDA, especialmente en lo que se refiere a la seguridad.

¡Use SSL! Todo el mundo usa SSL y tiene una LARGA historia de seguridad probada, y eso es algo que no puedes construir. SSL no solo resolvió Man in the Middle Attacks, sino que también puede usar Certificates en lugar de contraseñas para autenticar tanto al cliente como al servidor, lo que lo hace inmune a la fuerza bruta. El sol se consumirá antes de que un atacante pueda forzar un certificado RSA de 2048bit. Padre más, no tienes que preocuparte por un cuentagotas que olfatea la transmisión.

Tenga en cuenta que OpenSSL es GRATUITO, la generación de certificados es GRATUITA y el canto de certificados es GRATUITO. Aunque la única razón por la que desea firmar un certificado es si desea implementar una PKI, que probablemente no sea necesaria. El cliente puede tener la clave pública del servidor codificada para verificar la conexión. El servidor podría tener una base de datos de claves públicas del cliente. Este sistema sería autónomo y no requeriría OCSP o CRL o cualquier otra parte de una infraestructura de clave pública.

Answer 2

Su autenticación parece sólida pero propensa a man in the middle attacks ya que no garantiza la integridad de la conexión al servidor.

Sugiero implementar el protocolo SRP 6 en su lugar. Está comprobado que es seguro, garantiza la integridad de la conexión e incluso crea un secreto común que se puede usar para establecer algún tipo de cifrado simétrico. El protocolo parece un poco difícil a primera vista, pero en realidad es bastante fácil de implementar. También hay una demostración de JavaScript disponible en el project website y enlaces a varias implementaciones en diferentes idiomas.