"Si el sistema guarda mi contraseña cifrada, alguien con la llave la puede leer." La frase suena razonable, pero parte de un error de base: en un servicio bien hecho, tu contraseña no está cifrada, está hasheada. Y esa diferencia —una palabra que casi nadie distingue— cambia por completo lo que se puede y no se puede hacer con ella. Empecemos por lo primero.
Qué es un hash
Un hash es el resultado de pasar datos por una función hash: una operación matemática que resume cualquier entrada en una cadena corta y de longitud constante. No importa si le das una letra o un libro entero; la salida siempre mide lo mismo.
Una función hash toma una entrada de cualquier tamaño y devuelve una cadena de tamaño fijo —el hash o digest—. Con SHA-256, por ejemplo, la salida siempre son 256 bits, escribas lo que escribas.
Tres propiedades la definen: es determinista (la misma entrada da siempre el mismo hash), es unidireccional (del hash no se puede volver a la entrada) y un cambio mínimo en la entrada cambia el hash por completo (una coma de más y el resultado es irreconocible).
Esa última propiedad es la que hace útil al hash: como un solo carácter distinto produce un hash totalmente diferente, comparar dos hashes es una forma barata y fiable de saber si dos entradas son idénticas —sin tener que compararlas byte a byte—.
Hash vs cifrado: la diferencia clave
Aquí está el corazón del malentendido. Cifrar y hashear se parecen porque ambos transforman datos en algo ilegible, pero sirven para cosas opuestas.
Cifrar es reversible. Su propósito es proteger algo que después necesitas leer: guardas un archivo cifrado y, con la llave correcta, recuperas el original exacto. Sin ese "de vuelta", el cifrado no serviría de nada.
Un hash es irreversible por diseño. No hay ninguna "llave" que lo revierta, porque durante el proceso se pierde información de forma deliberada. Su propósito no es ocultar para luego recuperar, sino producir una huella que puedas volver a calcular y comparar. Un hash no se "desencripta" porque nunca se cifró.
| Característica | Hash | Cifrado |
|---|---|---|
| ¿Reversible? | No | Sí, con la llave |
| ¿Usa llave? | No | Sí |
| Tamaño de salida | Fijo | Depende de la entrada |
| Para qué sirve | Huella, verificación | Confidencialidad |
Por qué las contraseñas se guardan hasheadas
Con eso claro, la práctica correcta se explica sola. Un servicio serio nunca guarda tu contraseña tal cual —ni siquiera cifrada—: guarda su hash.
Cuando inicias sesión, el sistema toma lo que escribiste, lo hashea con la misma función y compara ese hash con el que tenía guardado. Si coinciden, escribiste la contraseña correcta; nunca hizo falta conocer la original. Así, aunque un atacante robe la base de datos completa, no obtiene las contraseñas: solo un montón de huellas irreversibles.
De ahí una consecuencia que mucha gente lee al revés: cuando un sitio te dice que "no puede recuperar tu contraseña, solo restablecerla", no es una limitación molesta —es buena señal—. Significa que no la tiene, solo su hash.
Salt: por qué dos contraseñas iguales no se ven iguales
Hashear la contraseña resuelve mucho, pero deja un flanco. Como el hash es determinista, dos usuarios que eligieron la misma contraseña tendrían exactamente el mismo hash en la base de datos. Y como las contraseñas comunes se repiten muchísimo, existen tablas precalculadas —las rainbow tables— que ya guardan el hash de millones de contraseñas típicas listas para revertir de un vistazo.
El salt es un valor aleatorio y único por usuario que se añade a la contraseña antes de hashear. Como cada usuario tiene un salt distinto, dos contraseñas iguales producen hashes distintos, y las tablas precalculadas dejan de servir: habría que rehacerlas para cada salt posible.
El salt no es secreto —se guarda junto al hash—; su valor está en ser único. Convierte un ataque masivo y barato en uno que hay que repetir usuario por usuario, que es justo lo que se busca.
Errores comunes
"Olvidé mi contraseña, mándenmela por correo." Si un sitio puede enviarte tu contraseña original, es que la guarda de forma recuperable —cifrada o en texto plano—, y eso es una mala señal. Un sitio correcto solo puede dejarte restablecerla, porque de su hash no hay vuelta atrás.
Más allá de ese clásico, estos son los tropiezos que se repiten:
- Usar un hash rápido de propósito general (como SHA-256) para contraseñas. SHA-256 está diseñado para ser veloz, y esa velocidad ayuda al atacante a probar millones de candidatas por segundo. Para contraseñas se usan hashes lentos y diseñados para eso —bcrypt, scrypt, Argon2—, que encarecen deliberadamente cada intento y resisten la fuerza bruta.
- Hashear sin salt. Deja la puerta abierta a las tablas precalculadas y hace visible qué usuarios comparten contraseña.
- Confundir "hashear" con "cifrar" al diseñar un sistema, y terminar guardando contraseñas de forma recuperable creyendo que están protegidas.
El otro uso: verificar integridad
Las contraseñas son solo la mitad de la historia. El hash tiene un segundo uso igual de importante: comprobar que un archivo no cambió.
Si calculas el hash de un archivo antes de enviarlo y quien lo recibe calcula el hash de lo que le llegó, basta comparar: si los dos hashes coinciden, el contenido es idéntico; si cambió un solo byte —una descarga corrupta, una manipulación—, el hash no coincide y se nota al instante. Eso es exactamente lo que hacen los checksums y la verificación de integridad en la transferencia de archivos.
El ángulo banca
En banca los dos usos del hash se cruzan a diario, en dos frentes distintos:
- Almacenamiento de credenciales. Las contraseñas de banca en línea y de sistemas internos se guardan con un hash lento y salt, nunca en texto plano ni cifradas de forma recuperable. Es una exigencia básica de cualquier auditoría de seguridad.
- Integridad de los lotes. Los archivos que se intercambian entre instituciones —lotes de pagos, conciliaciones— viajan con un hash del contenido: al recibirlos, la contraparte recalcula el hash y confirma que el lote llegó sin alteración. Es el mismo principio de integridad que sostiene una transferencia por SFTP.
Cifrar y hashear no son intercambiables. Uno protege para poder leer después; el otro produce una huella que nunca se revierte. Usar uno donde toca el otro —cifrar una contraseña que debería hashearse, o "esperar recuperar" un hash— es de los errores de seguridad más caros y frecuentes que existen. Y casi siempre empieza por creer que son la misma cosa.
