Vulnerabilidades SHA1

Debería leer el este artículo . HMAC es la opción preferida en cualquier caso. La forma en que utiliza el hash con clave lo expone a todas las debilidades del algoritmo de hash. Sin embargo, HMAC sigue siendo seguro porque su seguridad se basa en suposiciones menos sólidas sobre el algoritmo hash.

Tenga en cuenta que la forma opuesta de calcular el hash HASH (KEY || MESSAGE) (a diferencia de HASH (MESSAGE || KEY) como lo pretende hacer) se considera completamente insegura, ya que puede leer here y aquí .

SHA-1 no se rompe generalmente para cada tipo de caso de uso. Pero, se considera que proporciona una protección insuficiente contra los ataques de colisión, lo que lo hace inadecuado como algoritmo de firma, por ejemplo, en los certificados. Todavía es lo suficientemente seguro para usar en HMAC aunque es similar (pero no igual) a su caso de uso.

Por lo tanto, creo que SHA-1 en su enfoque actualmente solo puede romperse con fuerza bruta. Ya que SHA-1 es un hash diseñado para ser rápido, podría endurecer su parámetro adicional usando un secreto más largo o usando un algoritmo diseñado para ser más lento. Ambos enfoques hacen que la fuerza bruta sea más difícil ya que el atacante necesita más tiempo para probar todos los secretos posibles.

Además, debe usar un HMAC real como kaidentity señala en su respuesta porque es mejor use algo probado para inventar el suyo propio, especialmente si se trata de criptografía.

Conocer los parámetros y no conocer la clave frente a saber ninguno de los dos no hace mucha diferencia en el caso de las claves grandes, ya que cualquier bit adicional en la clave generará un SHA completamente diferente. Una pequeña ventaja puede ser para el atacante si supiera la longitud de su clave adicional secreta, pero si esa clave es lo suficientemente grande, no tendrá ningún problema. Si la clave es lo suficientemente grande, la fuerza bruta sería un intento inútil.

Los investigadores ahora tienen ejecutó con éxito un ataque de colisión contra SHA1 , que es como murió MD5

  

Los criptógrafos se refieren al ataque revelado el jueves como una colisión con "prefijo idéntico", lo que significa que le permite al atacante crear dos mensajes distintos que tienen el mismo valor hash. Esta variedad es menos poderosa que la colisión MD5 de "prefijo elegido" llevada a cabo por Flame. En este último caso, los atacantes pueden apuntar a uno o más archivos existentes, como el certificado digital que utiliza una empresa para autenticar su mecanismo de actualización. A pesar de que la colisión contra SHA1 es menos poderosa, los expertos en criptografía dijeron que cualquier ataque con un prefijo idéntico en el mundo real representaba un evento de finalización de juego para una función de hashing.

Hay un sitio web dedicado al ataque

  

Ahora es prácticamente posible crear dos archivos PDF en conflicto y obtener una firma digital SHA-1 en el primer archivo PDF, que también puede ser objeto de abuso como una firma válida en el segundo archivo PDF.

En otras palabras, deja de usar SHA1

Dependiendo de la implementación, una cosa que viene a la mente es que podría ser vulnerable a un ataque de extensión de longitud donde El atacante 'comienza' desde tu hash. No estoy seguro de que esto se aplique a usted, pero:

1. Sus parámetros son foo=1&bar=2
2. Se envían como foo=1&bar=2&sha(foo, bar, SECRET)
3. Un atacante que quiera inyectar o reemplazar un parámetro podría inicializar su hash SHA desde foo=1&bar=2&sha(foo, bar, SECRET) y agregar su parámetro

No entré en detalles técnicos porque no estoy seguro de que se aplique a usted; También hay algunos requisitos (en su mayoría, sabiendo la duración de la solicitud original) pero creo que están satisfechos con lo que entiendo de su descripción.

Además, su esquema es vulnerable a los ataques de repetición: ¿qué sucede si un atacante intercepta la transacción y la repite una y otra vez? Ya que es sobre HTTP eso sería trivial.