Seguridad

Generador HMAC

Calculá HMAC con SHA-1, SHA-256, SHA-384 o SHA-512. Útil para firmar webhooks (Stripe, GitHub), autenticar requests a APIs y verificar integridad con clave compartida.

Qué resuelve HMAC

Un hash como SHA-256 te dice si dos mensajes son idénticos, pero no te dice quién los generó. Cualquiera puede calcular el SHA-256 de un mensaje, así que no sirve para autenticar el origen. HMAC resuelve eso combinando el mensaje con una clave secreta de forma específica: solo quien conozca la clave puede producir el HMAC correcto.

Está estandarizado en la RFC 2104 (1997) y se construye sobre cualquier hash criptográfico. Las variantes más usadas hoy son HMAC-SHA-256, HMAC-SHA-384 y HMAC-SHA-512. HMAC-SHA-1 sigue funcionando pero ya no se recomienda para nuevas implementaciones.

Cómo se construye HMAC

La fórmula simplificada es HMAC(K, m) = H((K' xor opad) || H((K' xor ipad) || m)), donde:

  • H: la función de hash subyacente (SHA-256, SHA-512, etc.).
  • K': la clave normalizada al tamaño del bloque (rellena con ceros o hasheada si es muy larga).
  • ipad, opad: constantes específicas (0x36 y 0x5C repetidos).
  • m: el mensaje.

Esta doble pasada es lo que hace a HMAC resistente a ataques de extensión de longitud que afectan a esquemas naive como H(K || m).

Casos de uso típicos

  1. Verificación de webhooks. Stripe, GitHub, Slack y otros firman cada webhook con HMAC. Tu servidor recalcula la firma con el secret compartido y compara.
  2. Autenticación de APIs. AWS Signature v4, por ejemplo, usa HMAC-SHA-256 para firmar cada request.
  3. Cookies firmadas. Frameworks como Express o Django firman cookies para detectar manipulación.
  4. Tokens de un solo uso. Un token con tiempo de validez puede llevar el HMAC para evitar falsificación sin necesidad de tabla en base de datos.
  5. JWT con HS256. Internamente usa HMAC-SHA-256.

Buenas prácticas con HMAC

  • Comparación constant-time. Usá funciones como crypto.timingSafeEqual en Node, hmac.compare_digest en Python. Comparar string a string permite ataques de timing.
  • Clave de al menos 256 bits. Para HMAC-SHA-256 una clave de 32 bytes random es lo recomendado. Para HMAC-SHA-512, 64 bytes.
  • No reutilices la clave para otra función. Una clave debería servir para un único propósito.
  • Rotá las claves. Como cualquier secreto, deben rotar periódicamente.
  • Incluí timestamp. Para evitar replay attacks, firmá el cuerpo más un timestamp y rechazá firmas viejas.

HMAC vs firma asimétrica

HMAC usa una clave compartida: tanto el firmante como el verificador la conocen. Eso es simple y rápido, pero significa que cualquiera de las partes puede generar firmas válidas: no podés probar quién firmó.

Las firmas asimétricas (RSA, ECDSA, EdDSA) usan una clave privada para firmar y una pública para verificar. Solo el dueño de la privada puede firmar, así que sí podés atribuir firmas. La contracara: son más lentas y la clave privada hay que protegerla muy bien.

Para webhooks entre dos partes que confían entre sí, HMAC es ideal. Para distribución pública o auditabilidad, conviene firma asimétrica.

Privacidad de este generador

Todo se calcula con crypto.subtle.sign, la implementación nativa del navegador. Tu mensaje y tu clave nunca salen de tu equipo. En producción, igual no deberías confiar en que el HMAC se calcule en el navegador: el secret tiene que vivir en el servidor.

Preguntas frecuentes

¿Qué es HMAC?

Una construcción que combina hash y clave secreta para autenticar mensajes. Permite verificar que un mensaje viene de quien comparte la clave.

¿Diferencia con un hash?

Un hash cualquiera puede recalcularlo. HMAC requiere clave: solo quien la tenga puede generar o verificar.

¿Qué algoritmo elegir?

HMAC-SHA-256 es el estándar actual. SHA-512 da más bits pero rara vez hace falta. SHA-1 deprecado.

¿Es seguro en el navegador?

Sí, usa Web Crypto. En producción igual, la firma debe generarla el servidor para no exponer el secreto.