Funciones hash: SHA-256, sumas de comprobación y hash de contraseñas
Una función hash convierte cualquier entrada —una palabra, una contraseña, un archivo de 4 GB— en una huella breve de longitud fija. La misma entrada da siempre la misma huella, y el cambio más pequeño da una completamente distinta. Por eso los hashes son la forma habitual de comprobar que un archivo ha llegado intacto, de guardar contraseñas sin conservar las propias contraseñas y de firmar mensajes. Esta guía explica qué hace que un hash sea seguro, qué algoritmos siguen siendo fiables, cómo comprobar una descarga y por qué el hash rápido que conviene para un archivo es el equivocado para una contraseña.
Qué hace una función hash
Una función hash lee datos de cualquier longitud y devuelve un resumen de longitud fija. SHA-256, la más común hoy en día, devuelve siempre 256 bits, escritos como 64 caracteres hexadecimales, tanto si la entrada es una sola letra como si es la imagen de un disco entero.
c3c211099e2db0d1bb97343886c2b7e23981b636107a296a9fe642b99ca4cc1bSHA-256 de nTools.420849368aee5e9b6838f98b4dde3f493de84c420baa785ea58a08acc2c0cfafSHA-256 de ntools: basta pasar una letra a minúscula para obtener un resumen sin ninguna relación.
Toda función hash es determinista —la misma entrada da el mismo resumen en cualquier equipo— y rápida de calcular. Un hash criptográfico añade las garantías de la sección siguiente, que son las que permiten usarlo en seguridad.
Un resumen no es una copia comprimida: 64 caracteres no pueden contener un archivo de 4 GB. En teoría, muchas entradas comparten cada resumen; un hash seguro simplemente hace que sea inviable encontrarlas en la práctica.
Qué hace que un hash sea seguro
La norma estadounidense que define SHA-256, FIPS 180-4, considera seguros estos algoritmos porque ciertas búsquedas son computacionalmente inviables. En la práctica se trata de tres propiedades:
- Resistencia a preimágenes: dado un resumen, nadie puede encontrar una entrada que lo produzca. Esto es lo que significa «unidireccional».
- Resistencia a segundas preimágenes: dado un archivo, nadie puede crear otro distinto con el mismo resumen.
- Resistencia a colisiones: nadie puede encontrar dos entradas distintas cualesquiera con el mismo resumen, aunque elija ambas libremente.
La resistencia a colisiones es la primera en caer, porque el atacante controla las dos entradas. Eso es lo que les pasó a MD5 y SHA-1. Es importante porque las firmas digitales y los certificados se calculan sobre un hash del documento: dos documentos con el mismo hash comparten la misma firma.
MD5, SHA-1, SHA-2 y SHA-3
| Algoritmo | Resumen | Estado |
|---|---|---|
MD5 | 128 bits, 32 caracteres hexadecimales | Roto: encontrar colisiones es factible en la práctica. El RFC 6151 (2011) lo descarta allí donde se requiere resistencia a colisiones, como en las firmas digitales. |
SHA-1 | 160 bits, 40 caracteres hexadecimales | Roto: primera colisión pública en 2017. El NIST indica que debe dejar de usarse, de forma progresiva, a más tardar el 31 de diciembre de 2030. |
SHA-256 | 256 bits, 64 caracteres hexadecimales | Seguro. Forma parte de la familia SHA-2 (FIPS 180-4) y es la opción habitual por defecto hoy en día. |
SHA-384, SHA-512 | 384 y 512 bits, 96 y 128 caracteres hexadecimales | Seguros. También son SHA-2, con un resumen más largo. |
SHA-3 | De 224 a 512 bits, según la variante | Seguro. Estandarizado en 2015 (FIPS 202) con un diseño distinto, Keccak, para complementar a SHA-2, no para sustituirlo. |
La colisión de SHA-1, llamada SHAttered, la anunciaron Google y el CWI Amsterdam el 23 de febrero de 2017: dos archivos PDF distintos con el mismo resumen SHA-1, encontrados tras unos 9,2 trillones de cálculos SHA-1. Desde entonces, MD5 y SHA-1, como hashes simples, solo sobreviven como comprobaciones rápidas frente a daños accidentales. La documentación de Microsoft sobre el comando de Windows que calcula el hash de un archivo dice lo mismo: deben usarse solo para validar cambios de forma sencilla, nunca para archivos que haya que proteger de manipulaciones.
El generador de hash de nTools ofrece SHA-256, SHA-384 y SHA-512. Usa la Web Crypto API integrada en el navegador, que también admite SHA-1 —con la advertencia de no usarlo en criptografía— y no ofrece MD5 en absoluto.
Cómo comprobar una descarga
Los editores de software suelen publicar una suma de comprobación junto al archivo, normalmente SHA-256. Tras la descarga, calculas el resumen de tu copia y comparas ambos valores.
- Fíjate en qué algoritmo usó el editor y copia la suma de comprobación publicada.
- Calcula el resumen del archivo descargado con el mismo algoritmo: en el generador de hash de nTools para archivos de hasta 200 MB, o con un comando como los de abajo para cualquier tamaño.
- Compara todos los caracteres, no solo los primeros y los últimos. En hexadecimal, las mayúsculas y las minúsculas no importan.
Get-FileHash .\file.isoWindows PowerShell. Usa SHA-256 salvo que añadas -Algorithm.sha256sum file.isoLinux.shasum -a 256 file.isomacOS.
Que coincidan demuestra que el archivo es el mismo del que se calculó el hash; no demuestra quién lo calculó. Un atacante capaz de sustituir el archivo en un sitio normalmente también puede sustituir la suma de comprobación de la misma página. Por eso proyectos como Ubuntu firman además su lista de sumas de comprobación: primero verificas la firma con GPG y después el archivo con la lista. Una vez comprobada la huella de la clave de firma en el propio sitio del proyecto, el resultado es válido aunque hayas descargado el archivo de un servidor espejo que no sea de confianza.
Hash, cifrado y codificación
| Método | ¿Reversible? | ¿Clave? | Para qué se usa |
|---|---|---|---|
| Hash (p. ej., SHA-256) | No | No | Comprobar la integridad, identificar datos, guardar contraseñas con un algoritmo lento |
| Cifrado (p. ej., AES) | Sí, con la clave | Sí | Mantener los datos en secreto |
| Codificación (p. ej., Base64) | Sí, cualquiera puede | No | Transportar datos binarios como texto, en correos electrónicos, URL y JSON |
Base64 y la codificación URL no protegen nada: cambian la forma en que se escriben los datos, no quién puede leerlos. Además, guardar las contraseñas cifradas es peor que guardarlas como hash, advierte OWASP: el cifrado funciona en ambos sentidos, así que quien pueda descifrarlas recupera las contraseñas originales. Solo tiene sentido en el raro caso de que haya que recuperar el original.
Por qué un hash rápido no sirve para contraseñas
Un sitio nunca debería guardar tu contraseña, solo un hash de ella: al iniciar sesión, calcula el hash de lo que escribes y compara el resultado. El problema es la velocidad. Un hash que comprueba una descarga de 4 GB en segundos permite a quien robe la base de datos probar miles de millones de intentos por segundo.
| Algoritmo | Intentos por segundo, una RTX 4090 | Tiempo para probar todas las contraseñas de 8 caracteres con minúsculas y dígitos |
|---|---|---|
| MD5 | 164.000 millones | 17 segundos |
| SHA-1 | 51.000 millones | 56 segundos |
| SHA-256 | 22.000 millones | 2 minutos |
| SHA-512 | 7500 millones | 6 minutos |
| PBKDF2-HMAC-SHA256, 600.000 iteraciones | unos 15.000 | unos 6 años |
| bcrypt, coste 10 | unos 5750 | unos 15 años |
Velocidades de la prueba de rendimiento de hashcat 6.2.6 con una sola tarjeta gráfica NVIDIA RTX 4090. Las dos últimas filas se han extrapolado a partir de la configuración de la propia prueba (999 iteraciones de PBKDF2, bcrypt con coste 5), porque el tiempo crece en proporción al trabajo. La búsqueda abarca todas las candidatas, 36⁸, unos 2,8 billones. Los ataques reales son aún más rápidos: usan muchas tarjetas a la vez y prueban primero las contraseñas más probables.
Sal: la misma contraseña, un hash distinto
Sin sal, todas las personas cuya contraseña es 123456 tienen el mismo hash almacenado, y los atacantes guardan tablas con los hashes de millones de contraseñas comunes, así que encontrarlas es cuestión de consultar una tabla, no de hacer una búsqueda.
8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92SHA-256 de 123456, sin sal: el mismo en todas las bases de datos que lo guardan así.
Una sal es un valor aleatorio que se crea para cada contraseña, se guarda junto a su hash y se mezcla con ella al calcularlo. No es secreta. Su función es que cada hash almacenado sea único, de modo que las tablas precalculadas no sirvan de nada y haya que atacar cada cuenta por separado.
La guía NIST SP 800-63B-4 exige que las contraseñas se guarden con sal y con un hash calculado mediante un esquema de hash de contraseñas adecuado, con una sal de al menos 32 bits, y recomienda un factor de coste tan alto como sea viable. También recomienda un paso adicional con clave, usando una clave secreta guardada aparte de los hashes, idealmente en un módulo de seguridad de hardware. OWASP llama a ese secreto pimienta (pepper).
Qué usar en su lugar
Las funciones de hash de contraseñas son lentas a propósito, reciben la sal como entrada y tienen un parámetro de coste que debería aumentar a medida que el hardware se vuelve más rápido. La Password Storage Cheat Sheet de OWASP establece estos mínimos:
| Algoritmo | Configuración mínima | Cuándo |
|---|---|---|
Argon2id | 19 MiB de memoria, 2 iteraciones, paralelismo 1 | Primera opción. Cada intento necesita memoria, lo que reduce la ventaja de las tarjetas gráficas. Especificado en el RFC 9106 (2021). |
scrypt | N = 2¹⁷, r = 8, p = 1 | Cuando Argon2id no está disponible. También necesita memoria. |
bcrypt | Coste 10 o más | Sistemas antiguos. La mayoría de las implementaciones aceptan como máximo 72 bytes de contraseña; las más largas se truncan o se rechazan. |
PBKDF2-HMAC-SHA256 | 600.000 iteraciones | Cuando se exige cumplir FIPS-140. |
Son mínimos, pensados para que un inicio de sesión tarde una fracción de segundo en el servidor y, a la vez, cada intento salga caro. No puedes ver cuál usa un sitio, y por eso los consejos de la guía de contraseñas —larga, aleatoria y nunca reutilizada— parten del peor caso.
HMAC: un hash con clave
Un hash simple demuestra que los datos no han cambiado, pero cualquiera puede calcularlo: quien altere los datos puede recalcular el hash sin más. HMAC, definido en el RFC 2104 en 1997, mezcla una clave secreta con el hash, de modo que solo quien tenga la clave puede generar o comprobar el resultado.
Así es como las API firman las solicitudes, como los webhooks demuestran que proceden de su remitente y como se firman muchos JSON Web Tokens: el algoritmo JWT HS256 es HMAC con SHA-256.
Preguntas frecuentes
¿Se puede revertir un hash?
No. El resumen no contiene la entrada, así que no hay nada que decodificar. Lo que hacen los atacantes es adivinar: calculan el hash de candidatas hasta que una coincide. Eso funciona con entradas cortas o comunes, como las contraseñas, y fracasa con las largas y aleatorias.
¿Sigue sirviendo MD5 para algo?
Para detectar cambios accidentales, como una copia dañada o un archivo duplicado, sí. No donde alguien pueda manipular los datos a propósito, y nunca para contraseñas ni firmas.
¿Pueden dos archivos tener el mismo resumen SHA-256?
En teoría, sí: hay más archivos posibles que resúmenes. En la práctica, nunca se ha encontrado una colisión en SHA-256 completo, y una búsqueda por fuerza bruta requeriría unos 2¹²⁸ intentos.
¿Un resumen más largo es siempre más seguro?
Solo hasta cierto punto. Con 256 bits, una búsqueda de colisiones ya queda muy fuera de alcance; importa más la solidez del algoritmo, como demostró SHA-1. SHA-384 y SHA-512 se usan cuando alguna norma los exige o para tener un margen adicional.
¿Se sube mi archivo cuando calculo su hash en nTools?
No. El archivo se lee y su hash se calcula en tu navegador, y solo se muestra el resumen.
Anterior en la serie ← Fortaleza de las contraseñas explicada: longitud, entropía y frases de contraseña
Referencias
- NIST FIPS 180-4 — Secure Hash Standard (SHS) (August 2015)
- NIST FIPS 202 — SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions (August 2015)
- RFC 6151 — Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms (March 2011)
- NIST — NIST Retires SHA-1 Cryptographic Algorithm (December 2022)
- EFF — Cryptographers Demonstrate Collision in Popular SHA-1 Algorithm (February 2017)
- MDN Web Docs — SubtleCrypto: digest() method
- Microsoft Learn — Get-FileHash
- Ubuntu — How to verify your Ubuntu download
- hashcat v6.2.6 benchmark, NVIDIA GeForce RTX 4090
- NIST SP 800-63B-4 — Authenticators: password verifiers (July 2025)
- OWASP — Password Storage Cheat Sheet
- RFC 9106 — Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications (September 2021)
- RFC 2104 — HMAC: Keyed-Hashing for Message Authentication (February 1997)
- RFC 7518 — JSON Web Algorithms (JWA) (May 2015)
Guías relacionadas
- Direcciones IP explicadas: IPv4, IPv6 y los rangos reservados
- Subredes y CIDR explicados: prefijos, máscaras y hosts utilizables
- Registros DNS explicados: A, AAAA, CNAME, MX, TXT y NS
- ¿Está caído un sitio web o solo te pasa a ti? Cómo comprobarlo paso a paso
- Códigos de estado HTTP y errores de Cloudflare: qué significan 403, 404, 429, 500, 503 y 521
- Marcas de tiempo Unix y zonas horarias explicadas
- Contar fechas: días entre fechas, años bisiestos y semanas ISO
- Formatos de imagen explicados: JPEG, PNG, WebP, AVIF y HEIC
- Fortaleza de las contraseñas explicada: longitud, entropía y frases de contraseña
- Los UUID explicados: v4, v7 y cómo elegir la versión adecuada
- Los códigos QR explicados: capacidad, corrección de errores y tamaño de impresión
- Porcentajes e IVA explicados: añadir, quitar y encadenar
- Errores comunes en JSON y cómo corregirlos
- Editar PDF en el navegador: qué se conserva al unir, dividir y convertir