Generador de Hash y HMAC
- MD5inseguro
- SHA-1inseguro
- SHA-256
- SHA-512
MD5 y SHA-1 están rotos y no deben usarse para contraseñas ni firmas. Siguen valiendo para checksums y claves de caché.
Nada de lo que escribes aquí se almacena, registra ni comparte.
Escribe o pega texto para ver a la vez sus hashes MD5, SHA-1, SHA-256 y SHA-512, o cambia a HMAC para firmarlo con una clave secreta. Todo se ejecuta en tu navegador, así que ni tu texto ni tu clave salen de tu dispositivo.
Cómo usarlo
- Pega tu texto en el campo de entrada.
- Los cuatro hashes se calculan mientras escribes.
- Copia cualquier hash con el botón que tiene al lado.
Qué garantiza un hash
Un hash criptográfico transforma una entrada de cualquier longitud en un resumen de tamaño fijo, de forma determinista: los mismos bytes siempre dan el mismo resultado, y cambiar un solo bit cambia aproximadamente la mitad de la salida. Tres propiedades lo hacen útil, y cada uso necesita unas u otras.
La resistencia a preimagen significa que, dado un resumen, no se puede encontrar una entrada que lo produzca. La resistencia a segunda preimagen significa que, dada una entrada, no se puede encontrar otra distinta con el mismo resumen. La resistencia a colisiones significa que no se pueden encontrar dos entradas cualesquiera que colisionen, y es la más débil de las tres frente a un ataque, porque el atacante elige ambos lados.
Esa última distinción explica por qué un algoritmo roto no está igual de roto para todos los usos. Las colisiones de MD5 se producen en segundos, pero nadie puede invertir un resumen MD5, así que usar MD5 como clave de caché o como suma de verificación sin adversario es aceptable, mientras que usarlo como firma no lo es.
El estado de cada algoritmo
MD5 se considera roto desde 2004, y las colisiones de prefijo elegido - en las que un atacante fabrica dos documentos con contenido distinto que dan el mismo hash - hoy son baratas. Se utilizó para falsificar una autoridad de certificación funcional en 2008 y en el malware Flame en 2012. Úsalo para sumas de verificación, ETags y claves de caché; nunca para nada que un adversario pueda aprovechar si lo subvierte.
SHA-1 siguió el mismo camino. La primera colisión práctica se demostró en 2017 con dos PDF, y en 2020 llegó una colisión de prefijo elegido con un coste de decenas de miles de dólares. Los navegadores dejaron de aceptar certificados SHA-1 hace años y Git lleva tiempo migrando. Trátalo como un MD5 que duró algo más.
SHA-256 y SHA-512 son los valores por defecto actuales y no tienen debilidades prácticas conocidas. Ambos pertenecen a la familia SHA-2; SHA-512 suele ser más rápido en hardware de 64 bits pese a su salida más larga. SHA-3 existe como respaldo de estructura distinta, no como sustituto, y BLAKE3 merece conocerse cuando importa la velocidad con archivos grandes.
HMAC, y por qué no basta con hacer hash de la clave junto al mensaje
Un hash simple no demuestra nada sobre quién lo generó, porque cualquiera puede calcularlo. HMAC añade una clave secreta, así que un resumen que coincide demuestra que el remitente conocía la clave y que el mensaje no se ha alterado. Es lo que firma los webhooks de Stripe, GitHub y todos los demás, y lo que autentica las peticiones a la API de AWS.
La construcción intuitiva - hacer hash de la clave seguida del mensaje - es insegura con la familia SHA-2, porque son funciones Merkle-Damgård y su resumen es todo su estado interno. Un atacante con un resumen válido puede continuar desde ese estado y añadir datos, obteniendo un resumen válido para un mensaje más largo sin conocer nunca la clave. La estructura anidada de HMAC, que hace hash dos veces con dos claves derivadas, es lo que lo impide.
Hay algo que conviene hacer bien al verificar: comparar los resúmenes en tiempo constante. Una comparación de cadenas normal termina en cuanto encuentra una diferencia, y esa diferencia de tiempo es medible con suficientes peticiones, lo que permite a un atacante recuperar una firma byte a byte. La mayoría de lenguajes ofrecen una función específica para esto.
Un hash no es cifrado ni sirve para guardar contraseñas
El hash es unidireccional y no tiene clave: no hay nada que descifrar ni forma de recuperar la entrada. Si necesitas recuperar los datos, lo que quieres es cifrado, que es una herramienta completamente distinta.
Para contraseñas, un hash rápido es justo la elección equivocada. La velocidad favorece al atacante: un equipo doméstico prueba miles de millones de conjeturas SHA-256 por segundo contra una base de datos robada, y los resúmenes sin sal pueden consultarse directamente en tablas precalculadas. Guardar contraseñas requiere una función deliberadamente lenta y exigente en memoria, con una sal por contraseña: bcrypt, scrypt o Argon2id, que es la recomendación actual.
Hay un mal uso más sutil que conviene nombrar: hacer hash de un identificador para anonimizarlo. Hacer hash de correos o teléfonos no protege nada, porque el espacio de entradas posibles es lo bastante pequeño como para enumerarlo. Cualquiera con el resumen puede calcular el hash de todas las direcciones que tenga y comparar. El hash de un valor de baja entropía es una clave de búsqueda, no una anonimización.
Verificar una descarga, paso a paso
Una suma de verificación publicada responde a una sola pregunta: ¿los bytes que recibí coinciden con los bytes que tenía quien publicó el archivo? Calcula el hash del archivo en tu máquina - shasum -a 256 file.iso en macOS, sha256sum en Linux, Get-FileHash en PowerShell - y compara el digest con el que aparece en la página de descarga. Un solo carácter distinto significa que no es el mismo archivo.
Lo que esa comparación no te dice es si la página de quien publica era auténtica. Si un atacante puede cambiar la descarga, normalmente también puede cambiar la suma de verificación que está al lado, y por eso los proyectos serios firman el archivo de sumas con una clave GPG en lugar de limitarse a publicar el digest. Verificar la firma y después la suma es la cadena que de verdad demuestra algo.
Esa es también la razón de que MD5 siga siendo aceptable como suma de verificación en un escenario sin adversario e inaceptable para una firma. Frente a una descarga corrupta, MD5 funciona bien; frente a alguien que quiere que dos archivos tengan el mismo digest, está roto desde 2004.
Los hashes como direcciones, no solo como comprobación
Buena parte de la infraestructura moderna identifica el contenido por su hash y no por un nombre. Git nombra cada objeto con el digest de su contenido, y por eso el identificador de un commit es estable, delata cualquier manipulación y no depende de dónde viva el repositorio. Los digests de imágenes de contenedor funcionan igual, al igual que los archivos de lock de paquetes, que fijan una dependencia a unos bytes exactos en lugar de a un número de versión que alguien podría volver a publicar.
La deduplicación usa la misma idea: un sistema de respaldo que calcula el hash de cada bloque guarda los bloques idénticos una sola vez, y una red de distribución de contenido puede cachear por digest sin riesgo de servir datos viejos, porque un contenido distinto tiene una dirección distinta.
Los árboles de Merkle lo llevan más lejos. Al hashear pares de hashes hacia arriba se obtiene un único digest raíz que se compromete con todo un conjunto de datos, y eso es lo que permite a un cliente verificar que un elemento pertenece a él sin descargarlo todo. Los registros de transparencia de certificados, las cadenas de bloques y varias bases de datos replicadas se apoyan en esa estructura.
Verificar bien la firma de un webhook
El patrón es el mismo en Stripe, GitHub, Slack y casi todos los demás. Quien envía calcula un HMAC del cuerpo crudo de la petición con un secreto compartido y pone el digest en una cabecera; quien recibe lo vuelve a calcular y compara. Cuatro detalles deciden si la implementación es sólida.
Primero, hashea el cuerpo crudo, no una versión reserializada del JSON ya parseado: el orden de las claves y los espacios cambian los bytes y, con ellos, el digest. Segundo, compara en tiempo constante, porque una comparación de cadenas normal filtra dónde está la primera diferencia y, con suficientes peticiones, ese tiempo se convierte en la firma. Tercero, incluye en el payload firmado la marca de tiempo que envía el remitente y rechaza todo lo que tenga más de unos minutos, o una petición capturada podrá reproducirse indefinidamente.
Cuarto, admite dos secretos a la vez. La rotación es imposible si quien recibe solo conoce uno, y lo habitual es aceptar cualquiera de los dos durante una breve ventana de solapamiento.
Elegir parámetros para el hash de contraseñas
Argon2id es la recomendación actual y, a diferencia de un hash simple, recibe parámetros: memoria, iteraciones y paralelismo. El costo de memoria es lo que derrota al hardware especializado, ya que las GPU y los ASIC tienen mucho más poder de cálculo que memoria rápida por núcleo. Un punto de partida común es 19 MiB con dos iteraciones, y más si el hardware lo permite.
La forma de ajustarlo es empírica. Mide en la máquina que lo va a ejecutar y elige el costo más alto que mantenga un inicio de sesión por debajo de un cuarto de segundo aproximadamente, sin olvidar que un pico de inicios de sesión multiplica ese costo por cada petición simultánea. bcrypt con un factor de trabajo de 12 sigue siendo aceptable y es más fácil de desplegar en algunos stacks; scrypt queda entre los dos.
La migración no requiere la contraseña de nadie. Guarda el algoritmo y los parámetros junto a cada digest, verifica según lo que diga el registro almacenado y vuelve a calcular el hash con la nueva configuración en el momento en que alguien inicia sesión correctamente. En unos pocos meses, la mayoría de las cuentas activas se pasa sola.
Cuándo el hash es la herramienta equivocada
Hashear un identificador para anonimizarlo no funciona, y vale la pena entender el motivo en vez de memorizarlo. Un hash es determinista y el espacio de entradas es pequeño: no hay tantas direcciones de correo ni tantos números de teléfono, así que quien tenga los digests puede hashear todos los candidatos que posee y cruzarlos. Varios esquemas de publicidad y analítica vendidos como respetuosos con la privacidad descansan justo en ese error.
Cuando de verdad necesitas comparar identificadores sin revelarlos, las primitivas son otras: hashes con clave, usando un secreto que nadie más tiene, o protocolos diseñados para la intersección privada de conjuntos.
Hay otros dos usos indebidos muy frecuentes. Un hash no es un algoritmo de compresión, porque de él no se puede recuperar nada. Y un hash no criptográfico como CRC32 o MurmurHash es excelente para tablas hash y sumas de verificación, e inútil allí donde un adversario elige la entrada, porque las colisiones se pueden fabricar a propósito para degradar una estructura de datos hasta convertirla en un recorrido lineal.
Preguntas frecuentes
- ¿Qué es HMAC y cuándo lo necesito?
- HMAC combina un hash con una clave secreta para demostrar que un mensaje viene de alguien que posee esa clave y que no ha sido alterado. Un hash simple no demuestra ninguna de las dos cosas, porque cualquiera puede recalcularlo. HMAC es lo que firma los payloads de webhook y las peticiones de API. Cambia al modo HMAC y aporta la clave.
- ¿Es seguro usar MD5?
- No para seguridad. MD5 tiene ataques de colisión prácticos y nunca debe usarse para contraseñas, firmas ni integridad frente a un atacante motivado. Sigue siendo perfectamente razonable para usos no adversariales como checksums, claves de caché y ETags, y por eso está incluido aquí.
- ¿Entonces cómo debo hashear contraseñas?
- Con ninguno de estos. Almacenar contraseñas requiere un algoritmo lento y con sal, diseñado para ello, como bcrypt, scrypt o Argon2. Un hash rápido de propósito general como SHA-256 se puede romper por fuerza bruta a miles de millones de intentos por segundo.
- ¿Se envía mi entrada a un servidor?
- No. Los hashes SHA usan la Web Crypto API del navegador y MD5 está implementado en JavaScript en la propia página, así que tu texto nunca sale de tu dispositivo.
- ¿Por qué MD5 no está en la Web Crypto API del navegador?
- Se dejó fuera deliberadamente por estar criptográficamente roto, así que aquí se implementa aparte. La implementación está verificada contra los vectores de prueba oficiales de la RFC 1321.
- ¿Funciona con tildes y otros idiomas?
- Sí. La entrada se codifica en UTF-8 antes de hashear, así que el español con tildes, el japonés, el chino, el coreano y los emoji producen exactamente los mismos hashes que cualquier herramienta estándar de línea de comandos.
Última actualización:
Incluye los pasos, el resultado esperado y el real. Elimina secretos y datos personales.