Una de las soluciones de pago para los sitios web proporciona la siguiente forma de crear hash de seguridad para el enlace de pago:
hash = sha1(private_key + payment_params_json + private_key);
¿Hay alguna razón en particular para usar el mismo private_key dos veces?
Este constructo puede (crudamente) proteger contra un ataque de extensión de longitud , que en particular afecta a los hashes creados usando Merkle-Damgård construcción (como MD5, SHA-1 y SHA-2 familia).
La esencia del ataque es que un atacante que conoce H(s || m) y m para un hash H , secreto s , y el mensaje m pueden falsificar un hash de la forma H(s || m || p || a) donde p es el relleno interno utilizado por la función hash y a es una cadena controlada por el atacante. Esto puede parecer difícil de explotar en la práctica, ya que p suele ser bytes en bruto como \x04\x04\x04\x04 . Sin embargo, considere un mensaje como un conjunto de parámetros de consulta HTTP: username=x&admin=false . Con este ataque, puede falsificar un mensaje "firmado" para username=x&admin=false\x02\x02&admin=true . Dependiendo de cómo se analizan los parámetros, el analizador de URL podría usar fácilmente el último valor de admin en lugar del anterior.
El secreto del hash al final del mensaje es, presumiblemente, un intento de defenderse contra este tipo de ataque. Dado que el atacante no conoce el secreto, no puede usar un ataque de extensión de longitud ya que no tienen forma de falsificar H(s || m || p || a || s) sin saber s .
Dicho esto, hay construcciones criptográficas existentes que son probadas seguras para su uso como códigos de autenticación de mensajes. En este caso, HMAC es probablemente la primitiva criptográfica que desean usar, ya que tiene una fuerte prueba de seguridad.
Este tipo de construcción de origen local es evidencia de que los autores de este servicio no son no bien versados en criptografía. Si lo fueran, un HMAC sería una elección natural y obvia para tal situación. Si se sienten cómodos publicando este tipo de construcciones vergonzosas en su documentación pública, personalmente me preocuparía la criptografía que implementan y usan internamente.
Voy a basar mi respuesta en un par de suposiciones como se muestra a continuación.
El uso de dos claves privadas en este caso no tiene beneficios viables para la seguridad, suponiendo que un tercero nunca haya accedido a la clave (por lo tanto, está viendo ataques criptográficos inversos).
Sin embargo, si la necesidad se deriva de la idea de que un tercero pueda acceder a una clave, entonces, si ambas claves privadas se almacenaron en ubicaciones separadas a las que no se puede acceder directamente desde la aplicación (por ejemplo, API / base de datos), entonces quizás agregaría otra capa de seguridad si sucediera lo peor.
Lea otras preguntas en las etiquetas hash encryption sha payment-gateway