Generador HMAC - Encriptación HMAC

Generador HMAC - Generar Códigos de Autenticación de Mensajes Online

HMAC (Código de Autenticación de Mensajes Basado en Hash) es la primitiva criptográfica que alimenta virtualmente cada esquema de autenticación API en producción: AWS Signature v4, firmas de webhooks Stripe, secretos de GitHub Actions, verificación de peticiones Slack, firma de peticiones Twilio, callbacks de eventos Mailgun, cada JWT con alg HS256/HS384/HS512, y la spec completa de tokens MAC OAuth 2.0 se reducen a HMAC en su núcleo. Estandarizado en RFC 2104 (Krawczyk, Bellare, Canetti, 1997) y probado seguro bajo suposiciones estándar sobre el hash subyacente, HMAC toma dos entradas — una CLAVE secreta compartida y un MENSAJE — y produce una firma de tamaño fijo que cualquiera con la clave puede re-derivar y comparar. Esto es fundamentalmente distinto de un hash plano como sha256(mensaje): sin la clave, un atacante puede computar su propio sha256 de cualquier mensaje manipulado y reemplazar el suyo; con HMAC, no pueden forjar una firma coincidente sin conocer la clave. Este generador corre la implementación completa WebCrypto del lado cliente y soporta las tres variantes de la familia SHA-2 (SHA-256 para la mayoría de usos modernos, SHA-512 para aplicaciones de alta seguridad, SHA-1 para sistemas legacy de los que debería estar migrando), con salida tanto hexadecimal (el formato universal text-safe para headers y archivos config) como base64 (el estándar para firmas JWT y muchas APIs auth). Nunca reutilice un secreto entre servicios, nunca lo incruste en código del lado cliente, y rote periódicamente. Consulta también nuestro Generador de Hash SHA-512 y Generador de Hash MD5.

¿Qué es HMAC?

HMAC (Código de Autenticación de Mensajes Basado en Hash) es un algoritmo criptográfico que combina una función hash con una clave secreta para crear un código de autenticación de mensaje.

Características clave:
- Verifica tanto integridad de datos como autenticidad
- Requiere clave secreta (compartida entre emisor/receptor)
- Basado en funciones hash estándar (SHA-256, SHA-512, etc.)
- Usado en APIs, JWTs, webhooks y comunicaciones seguras

HMAC = Hash(clave_secreta + mensaje)

Ejemplo:
Mensaje: "Hola, Mundo!"
Secreto: "miClaveSecreta"
HMAC-SHA256: a4e624d686e03ed2767c0abd85c14426b0b1157d2ce81d27bb4fe4bc1e4fa3a6

HMAC proporciona tanto autenticación (el emisor tiene la clave) como integridad (el mensaje no ha sido modificado). Es fundamental para APIs seguras, verificación de webhooks y firma de tokens.

¿Cómo genero un HMAC?

Generar un HMAC es simple:

1. Ingrese su mensaje/datos
2. Ingrese su clave secreta
3. Seleccione algoritmo hash (SHA-256 recomendado)
4. Elija formato de salida (hex o base64)
5. Haga clic en 'Generar HMAC'
6. Copie el código HMAC

Ejemplo:
Mensaje: "usuario=juan&accion=login"
Clave: "api_clave_secreta_123"
Algoritmo: HMAC-SHA256
Salida: Cadena hex de 64 caracteres

El mismo mensaje + clave siempre producirá el mismo HMAC. Esto es importante porque permite al receptor verificar el mensaje generando el HMAC con la misma clave y comparando resultados.

Nota de seguridad: Mantenga su clave secreta privada. Cualquiera con la clave puede generar HMACs válidos.

¿Para qué se usa HMAC?

HMAC se usa ampliamente para autenticación segura y verificación de integridad:

✓ Autenticación de API:
- Verificación de firma AWS
- Webhooks de GitHub
- Firma de solicitudes API
- Firmas OAuth

✓ JWT (JSON Web Tokens):
- Algoritmos HS256, HS384, HS512
- Verificación de firma de token
- Autenticación de usuario

✓ Integridad de Mensajes:
- Verificación de payload de webhook
- Detección de manipulación de datos
- Transmisión segura de mensajes

✓ Gestión de Sesiones:
- Firma de cookies
- Generación de tokens CSRF
- Validación de sesión

✓ Seguridad de Pagos:
- Verificación de transacciones
- Pasarelas de pago (Stripe, PayPal)
- Prevención de fraude

HMAC asegura tanto autenticidad (el emisor tiene la clave) como integridad (el mensaje no ha cambiado). Es esencial para cualquier sistema que necesite verificar que los datos provienen de una fuente confiable y no han sido modificados.

¿Qué algoritmo HMAC debería usar?

Elija basándose en sus necesidades de seguridad:

HMAC-SHA256 (Recomendado):
✓ Estándar de industria
✓ Rápido y seguro
✓ Salida hex de 64 caracteres
✓ Usado por la mayoría de APIs
✓ JWT HS256
✓ Balance perfecto entre velocidad y seguridad

HMAC-SHA512 (Más Seguro):
✓ Máxima seguridad
✓ Salida hex de 128 caracteres
✓ Mejor para datos de alto valor
✓ JWT HS512
✓ Use para aplicaciones financieras o de alta seguridad

HMAC-SHA1 (Legado):
⚠️ Obsoleto para proyectos nuevos
✓ Solo para compatibilidad legado
✓ Salida hex de 40 caracteres
✗ No use para sistemas nuevos

Recomendaciones:
- Para la mayoría de aplicaciones: Use HMAC-SHA256
- Para máxima seguridad: Use HMAC-SHA512
- Para APIs modernas: SHA-256 es el estándar
- Para sistemas legados: Solo use SHA-1 si es necesario

Evite SHA-1 para proyectos nuevos ya que tiene vulnerabilidades conocidas.

¿Cómo verifica HMAC los mensajes?

Proceso de verificación HMAC:

1. Emisor:
- Crea mensaje
- Genera HMAC con clave secreta
- Envía mensaje + HMAC

2. Receptor:
- Recibe mensaje + HMAC
- Genera HMAC del mensaje usando misma clave
- Compara HMAC generado con HMAC recibido
- Coincidencia = auténtico, sin manipulación
- No coincide = rechazar (manipulado o clave incorrecta)

Ejemplo:
Mensaje original: "transferir $100"
Clave: "secreto_compartido"
HMAC: abc123...

Si un atacante cambia a "transferir $1000":
- El nuevo HMAC no coincidirá
- El receptor rechaza el mensaje
- La manipulación es detectada

Protección HMAC:
✓ Previene manipulación de datos
✓ Verifica autenticidad del emisor
✓ Detecta modificaciones no autorizadas
✓ Asegura integridad del mensaje

Sin la clave secreta correcta, es imposible generar un HMAC válido. Esto hace a HMAC perfecto para verificar que los mensajes provienen de una fuente confiable y no han sido modificados en tránsito.

¿Cómo verifico o comparo una firma HMAC en esta herramienta?

Use el campo opcional 'Firma Esperada'. (1) Pegue el mensaje y la misma clave secreta que usó para producir la firma. (2) Elija el algoritmo y formato de salida coincidentes (hex o base64). (3) Pegue la firma que recibió — por ejemplo el valor tras 'sha256=' en un header X-Hub-Signature-256 de GitHub, o 'v1=' en un header Stripe-Signature — en 'Firma Esperada'. (4) Haga clic en Generar HMAC. La herramienta computa el HMAC y muestra un veredicto claro COINCIDE o NO COINCIDE.

La comparación es tolerante: el hex se compara sin distinguir mayúsculas y se ignoran los espacios, y el base64 se compara tratando base64url (-_) igual que el estándar (+/) e ignorando el relleno '=' final. Así puede pegar una firma tal como aparece en el header.

Si obtiene NO COINCIDE, las causas habituales son: clave incorrecta, bytes del mensaje distintos (JSON re-serializado, \r\n vs \n, espacios al final), algoritmo equivocado, o hex pegado mientras compara en modo base64. Nota: esta verificación en el navegador es para depurar. En código de producción, compare siempre con una función de TIEMPO CONSTANTE (crypto.timingSafeEqual en Node, hmac.compare_digest en Python) para evitar ataques de timing.

JWT dice base64url pero esta herramienta da base64 estándar — ¿cómo los comparo?

Las firmas JWT (HS256/HS384/HS512) se codifican como base64url SIN relleno: '+' pasa a '-', '/' pasa a '_', y se eliminan los caracteres '=' finales. La salida Base64 de esta herramienta es base64 ESTÁNDAR (con + / y relleno =). Así los mismos bytes de HMAC pueden verse distintos como texto aunque sean idénticos.

Dos formas seguras de comparar. (1) Lo más fácil: cambie el formato de salida a Hexadecimal en ambos lados — el hex no tiene ambigüedad +//-_, así que una firma JWT decodificada a hex siempre coincide. (2) O use el modo verificar de aquí: la comparación de 'Firma Esperada' ya normaliza base64url a base64 estándar e ignora el relleno '=', así que puede pegar un segmento de firma JWT crudo directamente en 'Firma Esperada' con Base64 seleccionado y aun así obtener COINCIDE correcto.

Para construir el signing-input de un JWT a mano: HMAC sobre base64url(header) + '.' + base64url(payload), luego base64url-codifique el resultado (quite '='). Cuando la firma no valida, el relleno mal puesto o +/ vs -_ es la razón más común.

¿Cómo verifico una firma de webhook Stripe / GitHub / Slack usando HMAC?

Los tres siguen el mismo patrón con detalles distintos. El proveedor de webhook POSTea un payload JSON a su endpoint junto con un header conteniendo una firma HMAC de ese payload exacto, computada usando un secreto compartido que configuró durante el setup del webhook. Su trabajo: recomputar el HMAC en el body recibido y comparar con el valor del header usando una comparación de TIEMPO CONSTANTE (==, ===, strcmp filtran info de timing; use crypto.timingSafeEqual en Node o hmac.compare_digest en Python). Si coinciden, la petición realmente vino del proveedor y no fue manipulada en tránsito; si no, rechace con 401. (1) Stripe: header 'Stripe-Signature: t=1234567890,v1=abc...', secreto empieza con 'whsec_', algoritmo HMAC-SHA256, payload firmado es timestamp + '.' + body. (2) GitHub: header 'X-Hub-Signature-256: sha256=abc...', secreto que estableció por repo, HMAC-SHA256 del body crudo. (3) Slack: header 'X-Slack-Signature: v0=abc...', signing secret de la config de la app, HMAC-SHA256 de 'v0:' + timestamp + ':' + body. Siempre rechace también si el timestamp tiene más de 5 minutos para prevenir ataques de replay.

¿Por qué mi HMAC computado en Python no coincide con el de Node.js?

Ocho de cada diez veces es un desajuste de encoding — está hasheando secuencias de bytes diferentes sin darse cuenta. Pase por esta checklist. (1) Encoding de clave: en JavaScript 'Buffer.from(secret)' asume UTF-8 por defecto pero '.from(secret, 'hex')' interpreta la misma cadena como bytes hex. Si su secreto parece '00ff42' podría ser valor hex de 3 bytes O cadena UTF-8 de 6 bytes '00ff42'. (2) Encoding del mensaje: mismo problema. La serialización JSON debe producir los mismos bytes exactos en ambos lados — incluso diferencias en orden de claves ({a:1,b:2} vs {b:2,a:1}) producen firmas diferentes. La mayoría de APIs requieren firmar la secuencia de bytes JSON cruda enviada por el cliente, no una versión re-serializada. (3) Encoding de salida: hex vs base64 vs base64 URL-safe difieren. (4) Saltos de línea: \n en Linux/Mac pero \r\n en el body desde cliente Windows; HMAC los ve como bytes distintos. (5) Espacios en blanco: espacios al final del mensaje. Solución: imprima los bytes exactos (Buffer.from(...).toString('hex')) en ambos lados para un mensaje pequeño conocido hasta que coincidan, luego pase al payload real.

¿Puedo usar HMAC para contraseñas?

¡NO! HMAC NO es para hasheo de contraseñas.

HMAC:
✓ Autenticación de mensajes
✓ Firmas API
✓ Integridad de datos
✗ NO para almacenamiento de contraseñas

Para contraseñas, use:
✓ bcrypt (recomendado)
✓ Argon2 (moderno)
✓ PBKDF2 (aceptable)
✗ Nunca HMAC

¿Por qué?
- HMAC es rápido (no es bueno para contraseñas)
- HMAC necesita una clave (las contraseñas son el secreto)
- HMAC no usa salt apropiadamente para contraseñas
- HMAC no está diseñado para ser lento (las funciones de contraseña deben ser lentas)

Diferencias:
HMAC: Verifica mensajes de una fuente conocida
Hasheo de Contraseñas: Almacena contraseñas de forma segura

¡HMAC y hasheo de contraseñas sirven propósitos diferentes y no son intercambiables!

Para autenticación API: Use HMAC
Para almacenar contraseñas: Use bcrypt/Argon2

Características Principales

• Generar HMAC desde cualquier mensaje instantáneamente
• Modo verificar: compare contra una firma esperada (COINCIDE / NO COINCIDE)
• Comparación tolerante: hex sin distinguir mayúsculas, base64url vs base64, sin relleno
• Soporte para SHA-256, SHA-512, SHA-1 y MD5 (verificado RFC 2104)
• Formato de salida Hexadecimal o Base64
• Clave secreta con alternancia mostrar/ocultar
• Web Crypto API para hasheo SHA (MD5 vía implementación en navegador)
• Copiar HMAC al portapapeles
• Descargar HMAC como archivo de texto
• Mostrar información de algoritmo y salida
• Soporte de modo oscuro
• Procesamiento 100% del lado del cliente
• Funciona sin conexión
• Sin registro requerido