Seguridad, criptografía: desafío estúpido - ¿Protocolo de respuesta?

Question

Ok chicos, solo un pequeño juego:

Tengo algunas especificaciones para un proyecto. En algún momento, solicitan lo siguiente para encriptar una contraseña a través de la red, diciendo que es un protocolo de respuesta de desafío:

CLIENT ----------------------------- SERVER

(1)ask for challenge -------------->

(2)    <---------------------------- send SHA1 taken from the time
                                       (this is the challenge)
(3) make SHA1 xor PASSWORD --------> if it's equal to SHA1 xor stored password

(4)    <---------------------------- Grant access

Para aquellos que no lo saben, SHA significa algoritmo de hash seguro, un algoritmo estándar para la criptografía.

Espero que esté claro. La pregunta es: si olfateo los paquetes 2 y 3 (el '' desafío '' y el '' desafío xor contraseña '', ¡tengo la contraseña real solo con otro xor entre los dos!?!? Hay otra forma de implementar este tipo de protocolo ??

Answer 1

¿Qué tal lo siguiente?

1. El servidor envía un desafío aleatorio
2. El cliente envía la suma de comprobación SHA1 de (desafío + contraseña)
3. Los servidores se comparan con la suma de comprobación SHA1 de (desafío + contraseña almacenada)

Answer 2

Podrías aplicar ingeniería inversa a la contraseña. Desea enviar el SHA de la contraseña, no la contraseña en sí. Implementar sus propios protocolos de seguridad casi nunca es una buena idea. ¿No puedes usar SSL o algo equivalente?

http://en.wikipedia.org/wiki/Cryptographic_nonce

Answer 3

Ese es un protocolo bastante horrible. Si esto es algo que alguien quiere que implemente, rehúse hacerlo. Existen protocolos revisados ??para este tipo de cosas. Si este es un juego en el que señalas todos los defectos, está bien.

• Cualquiera que escuche los pasos 2 y amp; 3 conoce la contraseña
• Cualquiera que escuche el paso 3 y observe que la hora puede forzar la contraseña por fuerza bruta si tiene alguna idea de la precisión del tiempo en el servidor
• Puedo pretender ser un servidor (envenenamiento por arp, eliminación de DNS, etc.) y obtener su contraseña, nunca completar el paso 4 y fingir un tiempo de espera
• Vulnerable para Man in the Middle Attacks porque no hay secreto compartido entre cliente / servidor o certificados en el servidor
• Confía en que el servidor almacena el SHA1 (tiempo) y espera una respuesta, por lo que puedo sobrecargar el servidor con solicitudes de desafíos y nunca responder.

Y definitivamente me falta un poco más.

Answer 4

Tiene razón: si captura el desafío y (desafía la contraseña XOR), extraer la contraseña es fácil.

Debe usar el cifrado adecuado en el paso 3, no XOR. Cifre el desafío con la contraseña.

Para dificultar la vida de un atacante, puede agregar datos aleatorios a lo que cifra: p. encriptar paddingCHALLENGEpadding. Al servidor no le importa cuál es el relleno, sabe dónde buscar el desafío, pero significa que un atacante no sabrá cuál es el texto plano completo.

Answer 5

Como los otros han señalado, tienes razón. También tenga en cuenta que alguien podría interceptar la comunicación (3) y potencialmente volver a enviarla mientras el usuario real está experimentando problemas de red (por ejemplo: un DDOS), el impostor se registraría y, a menudo, eso es suficiente para cambiar la contraseña (es decir, , muchos sistemas no requieren que proporcione una contraseña para cambiarla una vez que haya iniciado sesión).

Es posible que desee considerar HMAC (código de autenticación de mensaje hash con clave). He blogueado sobre esto en detalle aquí: http://blog.ciscavate.org/2007/09/creating-a-secure-webauth-system-part-1-hmac.html y daré un breve resumen a continuación.

HMAC es un método para garantizar que alguien con acceso a un secreto compartido haya generado un mensaje. HMAC utiliza algún tipo de función de hashing unidireccional (como MD5 o SHA-1) para cifrar el secreto junto con un mensaje. Esto genera un resumen breve de 16-20 bytes que actúa como una huella digital de la combinación de mensaje + secreto. Cuando se envía el resumen junto con el mensaje, el receptor (nuestro servidor) puede volver a generar el hash con el mismo cálculo HMAC y comparar el resumen generado localmente con el resumen que vino junto con el mensaje. Recuerde: el servidor también tiene el secreto, por lo que tiene suficiente información para confirmar el resumen. (Esto solo considera el problema de verificar el origen de un mensaje, pero puede usar el mismo enfoque para cifrar todo el mensaje, si usa un secreto diferente, diga un conjunto de claves públicas).

Answer 6

La forma en que haría esto es la siguiente:

1. Desafía al servidor.

2. El servidor responde con su clave pública (para, digamos encriptación RSA) digitalmente firmado.

3. El cliente verifica PK y cifra contraseña con la llave, luego firma digitalmente el cifrado contraseña.

4. El servidor verifica la firma y descifra la contraseña para almacenar / verificar.

La firma digital es importante aquí, ya que actúa como el comienzo de prevenir ataques de hombre en el medio.

Answer 7

Como otros han señalado, sí, este es un algoritmo de respuesta de desafío pobre.

Probablemente desee consultar Autenticación implícita , tal como lo utiliza HTTP. De hecho, si su protocolo está sobre HTTP, puede omitir escribir el suyo y simplemente usarlo o implementarlo.

Answer 8

cifrado de clave pública? Use la clave pública del servidor para cifrar la contraseña.

Answer 9

Aunque nunca es una buena solución implementar su propio protocolo criptográfico, y es algo que no sugeriría ...

Para superar el problema que enfrenta ... F - Una función que toma la contraseña y un valor pseudoaleatorio que aumenta monotónicamente y devuelve un número. Por ej. Hash (Hash (Contraseña) ^ Marca de tiempo)

1. Servidor: Solicitar desafío, Enviar (Marca de tiempo). Recuerde la última marca de tiempo enviada.
2. Cliente, Enviar respuesta (Enviar F (Contraseña, Marca de tiempo) y Marca de tiempo)
3. Servidor: Verifique el Cliente utilizando Hash (Contraseña) y Marca de tiempo enviada por el cliente (> Marca de tiempo enviada en Desafío).
4. Si el Cliente es correcto, otorgue acceso.
5. Asegúrese de que la marca de tiempo actual sea mayor que todas las marcas de tiempo enviadas por el cliente antes del próximo desafío para evitar ataques de reproducción.

Saludos cordiales, Ashish Sharma

Answer 10

¿Creo que el Diffie-hellman es un protocolo de intercambio de claves bien conocido y sólido?