security - Seguridad, criptografía: Stupid Challege-¿Protocolo de respuesta?
cryptography challenge-response (10)
Bueno chicos solo un pequeño juego:
Tengo algunas especificaciones para un proyecto. En algún momento, solicitan lo siguiente para cifrar una contraseña en 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 aspiro los paquetes 2 y 3 (el "desafío" y el "desafío xo contraseña", ¡sí tengo la contraseña real con otro xor entre ellos!) Hay otra forma de implementar este tipo de protocolo ??
Aunque nunca es una buena solución implementar su propio protocolo criptográfico, y es algo que no recomendaría ...
Para superar el problema al que se enfrenta ... F - Una función que toma la contraseña y un valor pseudoaleatorio monótonamente creciente y devuelve un número. Por ejemplo, Hash (Hash (Password) ^ Timestamp)
- Servidor: Preguntar por Desafío, Enviar (Indicación de fecha y hora). Recuerde la última marca de tiempo enviada.
- Cliente, Enviar respuesta (Enviar F (Contraseña, Marca de tiempo) y Marca de tiempo)
- Servidor: compruebe el cliente utilizando Hash (contraseña) y Timestamp enviados por el cliente (> Timestamp enviado en Challenge).
- Si el cliente es correcto, conceda acceso.
- 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 repetición.
Saludos cordiales, Ashish Sharma
Como otros han señalado, sí, este es un algoritmo de respuesta de desafío pobre.
Probablemente desee verificar la Autenticación implícita , tal como la utiliza HTTP. De hecho, si su protocolo es a través de HTTP, puede omitir escribir el suyo y simplemente usar o implementar esto.
encriptación de clave pública? Use la clave pública del servidor para encriptar la contraseña.
¿Qué tal lo siguiente?
- El servidor envía un desafío al azar
- El cliente envía la suma de comprobación SHA1 de (desafío + contraseña)
- Los servidores se comparan con la suma de comprobación SHA1 de (desafío + contraseña almacenada)
Como han señalado los otros, tienes razón. También tenga en cuenta que alguien podría interceptar la comunicación (3) y potencialmente reenviarla mientras el usuario real experimenta problemas de red (por ejemplo, un DDOS), el impostor estaría conectado y, a menudo, eso es suficiente para cambiar la contraseña (es decir , muchos sistemas no requieren que proporcione una contraseña para modificarla una vez que haya iniciado sesión).
Es posible que desee considerar HMAC (código de autentificación de mensaje hash-key). He escrito un blog sobre esto en detalle aquí: http://blog.ciscavate.org/2007/09/creating-a-secure-webauth-system-part-1-hmac.html y voy a dar un breve resumen a continuación .
HMAC es un método para garantizar que alguien que tenga acceso a un secreto compartido genere un mensaje. HMAC hace uso de algún tipo de función hash unidireccional (como MD5 o SHA-1) para encriptar el secreto junto con un mensaje. Esto genera un breve resumen de 16-20 bytes que actúa como una huella digital de la combinación mensaje + secreto. Cuando el resumen se envía junto con el mensaje, el receptor (nuestro servidor) puede volver a generar el hash con el mismo cálculo de 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 encriptar todo el mensaje, si usa un secreto diferente, por ejemplo, un conjunto de claves públicas).
Ese es un protocolo bastante horrible. Si esto es algo que alguien quiere que implemente, rechace hacerlo. Existen protocolos existentes y comprobados 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 3 sabe la contraseña
- Cualquiera que escuche el paso 3 y anote el tiempo puede usar la contraseña bruta si tiene alguna idea de la precisión del tiempo en el servidor
- Puedo fingir ser un servidor (envenenamiento arp, dns rediction, etc.) y obtener su contraseña, nunca completando el paso 4 y fingiendo un tiempo de espera
- Vulnerable a Man in the Middle Attacks porque no hay un secreto compartido entre el cliente / servidor o los certificados en el servidor
- Se basa 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 algo más.
La forma en que haría esto es la siguiente:
- Desafía al servidor.
El servidor responde con su clave pública (por ejemplo, encriptación RSA) firmada digitalmente.
El cliente verifica PK, encripta la contraseña con la clave y luego firma digitalmente la contraseña encriptada.
El servidor verifica la firma y descifra la contraseña para almacenarla / verificarla.
La firma digital es importante aquí ya que actúa como el comienzo de la prevención del hombre en los ataques del medio.
Sería capaz de realizar una ingeniería inversa de la contraseña. Desea enviar el SHA de la contraseña, no la contraseña en sí. Hacer rodar sus propios protocolos de seguridad casi nunca es una buena idea. ¿No puedes usar SSL o algo equivalente?
Tiene razón, si captura el desafío y (desafía la contraseña de XOR), es fácil extraer la contraseña.
Debe usar el cifrado adecuado en el paso 3, no en XOR. Encripta el desafío con la contraseña.
Para que la vida de un atacante sea más difícil, puedes agregar datos aleatorios a lo que cifras: por ejemplo, encriptar paddingCHALLENGEpadding. Al servidor no le importa qué es el relleno, sabe dónde buscar el desafío, pero significa que un atacante no sabrá qué texto completo es.
Creo que Diffie-hellman es un conocido y sólido protocolo de intercambio de claves?