Generador de HMAC

HMAC es el algoritmo detrás de la mayoría de los webhooks firmados, los encabezados de AWS Signature v4 y los tokens JWT HS256. Ingresa un mensaje y una clave secreta, elige una familia de hash, y este generador produce el HMAC exactamente como lo especifica la RFC 2104, útil para verificar lo que tu backend está a punto de enviar, o reproducir una firma que recibiste de una API.

Cómo calcular un HMAC

  1. 1

    Pega el mensaje

    Los bytes exactos a firmar, un payload de webhook, una solicitud canónica, o cualquier cadena.

  2. 2

    Ingresa la clave secreta

    Puede ser texto o hex. El generador la rellena o le aplica un hash hasta el tamaño de bloque según la RFC.

  3. 3

    Elige el algoritmo de hash

    SHA-256 es el predeterminado; elige SHA-1, SHA-384, SHA-512 o MD5 para compatibilidad con versiones anteriores.

  4. 4

    Copia la firma

    La salida es hex en minúsculas, lista para pegar en una configuración de webhook o en un encabezado de autorización.

HMAC bajo el capó

HMAC envuelve una función hash simple en una construcción con clave para que la firma no pueda ser falsificada sin la clave.

La receta de la RFC 2104

HMAC(k, m) = H((k' ⊕ opad) ∥ H((k' ⊕ ipad) ∥ m))

donde k' es la clave rellenada al tamaño de bloque de hash, opad = 0x5c repetido y ipad = 0x36 repetido.

Opciones de algoritmo

Algoritmo Tamaño de bloque Longitud de salida Recomendado para
HMAC-SHA-256 64 bytes 32 bytes Predeterminado moderno, firma de webhook
HMAC-SHA-384 128 bytes 48 bytes Firma de API de mayor seguridad
HMAC-SHA-512 128 bytes 64 bytes Tokens de larga duración
HMAC-SHA-1 64 bytes 20 bytes Legado (AWS S3 v2, OAuth 1.0)
HMAC-MD5 64 bytes 16 bytes Solo legado; evitar para nuevo trabajo

Dónde aparece HMAC

  • Webhooks de GitHub, Stripe, Shopify: encabezado X-Hub-Signature-256, Stripe-Signature, etc.
  • AWS Signature v4: una cadena de HMAC-SHA256 sobre la solicitud canónica.
  • JWT HS256: la firma del token es HMAC-SHA-256(header.payload, secret).
  • Tokens de restablecimiento de contraseña: HMAC sobre user_id + expiración + un secreto del sitio.

Errores comunes

  • Pasar una clave codificada en hex como texto en lugar de decodificarla a bytes primero.
  • Firmar los bytes de payload incorrectos: algunos webhooks firman el cuerpo de la solicitud en bruto incluyendo espacios en blanco, otros firman una forma canónica.
  • Usar == en JavaScript o Python para comparar firmas; usa siempre una comparación de tiempo constante para resistir ataques de temporización.

Preguntas frecuentes

Casi siempre porque los bytes del mensaje difieren. Firmar el cuerpo analizado en JSON introduce cambios de espacios en blanco; firma el cuerpo de la solicitud en bruto. También verifica que la clave esté decodificada de la misma manera (hex vs bytes en bruto) en ambos lados.

Sí. Si la clave es más corta que el tamaño de bloque de hash, se rellena con ceros; si es más larga, se le aplica un hash primero. La RFC 2104 recomienda claves de al menos la longitud de salida (32 bytes para SHA-256).

HMAC sigue siendo resistente a ataques de colisión conocidos de MD5 porque el ataque no se transfiere a la construcción de HMAC. Aún así, usa HMAC-SHA-256 para cualquier nuevo código, las herramientas y auditores lo esperan.

Sí. El mensaje y la clave secreta se envían a nuestro servidor a través de una conexión HTTPS cifrada para poder calcular el HMAC. Solo se usan para el cálculo y no se almacenan ni se registran.

Herramientas relacionadas

Herramienta disponible en otros idiomas