Estoy evaluando un procesador de tarjetas de crédito [1], y noté que están usando MD5 como parte de un algoritmo hash con sal para proteger una clave secreta. Como sé que el MD5 generalmente se considera roto, se siente como una mala solución. ¿Es eso suficiente criterio para rechazarlos como nuestro procesador? ¿Es posible demostrar un ataque?
(Si esto debería estar en un sitio de StackExchange diferente, hágamelo saber)
Aquí está el escenario específico, simplificado a los puntos salientes.
Credenciales
Primero, tengo una "clave secreta" de más de 30 caracteres y símbolos alfanuméricos superiores. (Por ejemplo, TUQ1ICGIIIK/PSBKNDFK=GNKOTHMMDBI ). También tengo un "ID de comerciante" de 12 dígitos. (Diga, 123456789012 .)
Formulario de pago accesible públicamente
En segundo lugar, el formulario de pago simplificado se ve algo así. (La forma real incluiría otros parámetros como nombre y dirección).
<form action="https://examplepaymentprocessor.com" method="POST">
<input name="MERCHANT" value="123456789012" />
<input name="TAMPER_PROOF_SEAL" value="d550a25dfb97697f5be928953ee7cfc4" />
<input name="TPS_DEF" value="MERCHANT AMOUNT TRANSACTION_TYPE" />
<input name="AMOUNT" value="10.00" />
<input name="TRANSACTION_TYPE" value="SALE" />
<!-- other input fields for credit card number, contact information, etc. -->
<input type="submit" value="Make Purchase" />
</form>
El "sello a prueba de manipulaciones" es el "resumen" de un hash MD5 de, en este caso, un "mensaje" compuesto por una concatenación de cadenas de:
- mi clave secreta,
- mi identificación de comerciante,
- el importe de la transacción, y
- el tipo de transacción
Por lo tanto, en este caso, MD5("TUQ1ICGIIIK/PSBKNDFK=GNKOTHMMDBI12345678901210.00SALE") = d550a25dfb97697f5be928953ee7cfc4 .
TPS_DEF le permite al usuario especificar el contenido específico del mensaje o, si lo prefiere, la clave secreta más un salt. El mensaje incluye, como mínimo, la clave secreta, pero podría incluir hasta todos los demás parámetros en el formulario. Mi ejemplo incluye la identificación del comerciante, la cantidad y el tipo de transacción.
Recuperación de datos
El proceso para recuperar transacciones de ejemplo es similar. A través de un formulario HTML (no accesible públicamente) o algún otro método para HTTP POST , puedo obtener información sobre una transacción determinada. (Supongamos que tengo un ID de transacción del procedimiento anterior).
<form action="https://examplepaymentprocessor.com/transaction_status" method="POST">
<input name="MERCHANT" value="123456789012" />
<input name="TAMPER_PROOF_SEAL" value="d550a25dfb97697f5be928953ee7cfc4" />
<input name="TPS_DEF" value="MERCHANT" />
<input name="TRANSACTION_ID" value="1234567890" />
<input type="submit" value="Get Info" />
</form>
Esto devolverá información que incluye todos los detalles de contacto del cliente y los últimos cuatro dígitos de su número de tarjeta de crédito. Tenga en cuenta que, de nuevo, usted (o un atacante) puede especificar el TPS_DEF como desee.
Ataque imaginado
Dado que MD5 es vulnerable a un ataque de prefijo elegido, he jugado con el uso de HashClash de Mark Stevens , pero eso parece crear dos mensajes nuevos con ciertos prefijos, en lugar de crear un segundo mensaje cuyo MD5 coincide con el primero. Sin embargo, parece que alguien con su propia clave secreta podría potencialmente crear una solicitud de estado de la transacción que haría un hash de tal manera que recuperaría los datos de mi en lugar de los suyos.
Preguntas
- ¿Qué tan probable es que un atacante pueda falsificar el "sello a prueba de manipulación indebida" para imitarme? ( O para transacciones falsificadas o para obtener información de clientes y transacciones, lo último es lo que creo que es más probable).
- ¿Hay otros ataques que puedas imaginar o demostrar?
- ¿Rechazarías este procesador? (Tenga en cuenta que son una combinación perfecta para nosotros en cualquier otro aspecto).
EDIT 1: Leer esta otra pregunta me hace pensar eso, desde el MD5 sigue siendo resistente a los ataques de pre-imagen, esta situación en particular es segura.
EDIT 2: Aclaré mi pregunta sobre un ataque relacionado con transacciones falsificadas y de información robada de clientes.
[1] No se menciona aquí. Envíeme un correo electrónico para obtener información específica.