La «sal» aparece en cuanto hablas del hashing de contraseñas. Añadir un valor aleatorio antes de aplicar el hash cambia drásticamente el panorama de seguridad. Aquí tienes cómo funciona y los puntos clave (sin pasos de ataque).
Por qué una sal hace más seguras las contraseñas
Sin una sal, los usuarios con la misma contraseña obtienen el mismo hash almacenado. Eso le da al atacante dos opciones: buscar la contraseña directamente en una tabla precalculada (una tabla arcoíris) y reutilizar el resultado de romper una cuenta para todos los que tienen la misma contraseña.
Añade una sal y la misma "password123" se almacena como algo completamente distinto para cada usuario.
Por la misma razón, la sal debe generarse de nuevo para cada usuario (idealmente para cada contraseña). Si todos comparten una sola sal, los usuarios con la misma contraseña vuelven a tener valores almacenados iguales, y se pierde la mayor parte del beneficio. Usa un generador de números aleatorios criptográfico, difícil de predecir, y guarda la sal junto al hash (no necesita ser secreta).
Una sal solo protege frente a las tablas precalculadas y el cracking masivo de contraseñas repetidas. Frenar un ataque de fuerza bruta contra una sola contraseña no es su trabajo; de eso se encarga un hash deliberadamente lento como bcrypt/Argon2. Cubren amenazas distintas, así que usa siempre ambos.
Longitud de la sal y cómo generarla
Dos documentos marcan la referencia:
- NIST SP 800-63B-4 (la guía de autenticación de EE. UU.): la sal debe tener al menos 32 bits y elegirse de forma que las sales almacenadas rara vez coincidan. Para cada contraseña se guardan tanto la sal como el hash
- RFC 9106 (la especificación de Argon2): se recomiendan 16 bytes (128 bits) para el hashing de contraseñas, reducibles a 64 bits cuando el espacio es limitado
Tres reglas para generarla:
- Usa un generador de números aleatorios criptográfico. Usa la función de aleatoriedad segura de tu lenguaje, no funciones predecibles como
Math.random()omt_rand()de PHP - No uses valores adivinables: un nombre de usuario, una dirección de correo, un ID de usuario o la hora de registro no sustituyen a una sal
- Genera una sal nueva cuando cambie la contraseña. Mantener la antigua deja un vínculo entre los hashes antiguo y nuevo
En la práctica, las implementaciones estándar de bcrypt, Argon2 y scrypt cumplen todo esto automáticamente. Si estás escribiendo código que crea sales por tu cuenta, tómalo como señal para revisarlo.
Sal frente a pimienta frente a estiramiento de claves
El almacenamiento de contraseñas implica tres medidas de nombre parecido. Defienden frente a cosas distintas, así que ninguna sustituye a otra.
| Sal | Pimienta | Estiramiento de claves (hash lento) | |
|---|---|---|---|
| Qué es | Un valor aleatorio por usuario | Un valor secreto compartido por todos los usuarios | Hacer deliberadamente costoso el cálculo del hash |
| ¿Es secreto? | No (se guarda con el hash) | Sí (se guarda fuera de la base de datos) | La configuración no necesita ser secreta |
| Defiende frente a | Tablas precalculadas, cracking masivo de contraseñas idénticas | Cracking cuando solo se filtra la base de datos | Fuerza bruta contra cada hash |
| Implementación | bcrypt/Argon2 la añaden automáticamente | La añades tú si hace falta | Coste de bcrypt, memoria e iteraciones de Argon2 |
NIST SP 800-63B-4 recomienda que una «clave secreta conocida solo por el verificador» (lo que suele llamarse pimienta) se guarde separada de los hashes de contraseñas, idealmente dentro de hardware dedicado como un HSM.
Caso real: almacenamiento sin sal en LinkedIn (2012)
En junio de 2012 se informó de que unos 6,5 millones de hashes de contraseñas atribuidos a usuarios de LinkedIn se habían publicado en internet. LinkedIn confirmó que algunos correspondían a cuentas de LinkedIn y desactivó las contraseñas de los miembros afectados.
En su blog oficial, la empresa dijo que había estado pasando de un sistema que solo aplicaba hash a las contraseñas a uno que aplicaba hash y sal. En aquel momento, expertos citados en la prensa criticaron a la empresa por proteger las contraseñas solo con hash SHA-1.
Dos lecciones:
- Los hashes sin sal permiten recuperar en masa las contraseñas comunes a partir de tablas precalculadas
- Incluso a mitad de una migración, si quedan hashes en el formato antiguo, el impacto de una filtración lo decide ese formato antiguo
Cómo comprobar tu propio entorno
Mira la forma de las cadenas almacenadas
En una base de datos de desarrollo que controles, mira algunos valores de contraseña. En bcrypt, los 22 caracteres tras $2b$12$ son la sal. En Argon2, a $argon2id$v=19$m=…,t=…,p=…$ le siguen la sal y el hash separados por $. Si el valor no encaja con ninguna de las dos formas y no hay una columna de sal aparte, puede que las contraseñas se guarden sin sal.
Crea dos cuentas de prueba con la misma contraseña
En un entorno de desarrollo, registra dos cuentas de prueba con la misma contraseña y compara los valores almacenados. Si coinciden, la sal no está funcionando. Confirma también que la parte de la sal cambia al cambiar una contraseña.
Busca código que construya sales a mano
Busca en el código la palabra salt y los lugares que combinan a mano funciones aleatorias o de hash. Si encuentras una función aleatoria predecible, un nombre de usuario o ID reutilizado o una cadena fija, sustitúyelo por la función de contraseñas estándar de tu lenguaje o framework.
Usa la guía práctica para la migración
Cómo migrar desde un almacenamiento sin sal (por ejemplo, volviendo a aplicar el hash al iniciar sesión) y la configuración recomendada para cada algoritmo se explican en cómo almacenar contraseñas con seguridad.
Conceptos erróneos comunes frente a la verdad
Concepto erróneo
- Una sal debe mantenerse en secreto
- Una sola sal compartida para todos los usuarios está bien
- Una sal hace seguras incluso las contraseñas débiles
La verdad
- Una sal puede ser pública (guárdala con el hash)
- Un valor aleatorio distinto por usuario (idealmente por contraseña)
- Una sal defiende contra «la precomputación y el cracking por reutilización»; la fuerza bruta la maneja un hash lento
La visión de este sitio: primero, sal y hash lento bien hechos
Una pimienta es una medida adicional para el caso en que solo se roba la base de datos. Añade el trabajo de gestionar un secreto en otro lugar, y si pierdes ese secreto ya no puedes verificar la contraseña de nadie.
Por eso, en la práctica, la primera prioridad es usar sal + un hash lento correctamente mediante bcrypt/Argon2. Plantéate una pimienta cuando ya tengas un sistema de gestión de claves en marcha.
Fuentes (primarias)
- NIST, "SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management" (agosto de 2025) — pages.nist.gov (sal de al menos 32 bits, guardar sal y hash, una clave secreta guardada aparte)
- RFC 9106, "Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications" — rfc-editor.org (sal de 16 bytes recomendada para el hashing de contraseñas)
- OWASP, "Password Storage Cheat Sheet" — cheatsheetseries.owasp.org (sal, pimienta, la mayoría de las bibliotecas gestionan las sales automáticamente)
- Formato de cadena PHC (el formato de cadena de hash que usan Argon2 y otros) — github.com/P-H-C
- TechCrunch, "LinkedIn Confirms Hack And Leak Of 'Some' User Passwords" (6 de junio de 2012) — techcrunch.com (unos 6,5 millones, declaración de la empresa sobre el paso a hash y sal)
- Computerworld, "LinkedIn provides breach update -- sort of" (8 de junio de 2012) — computerworld.com (críticas al hash solo con SHA-1, contraseñas invalidadas)
Sigue leyendo
- Glosario: qué es el hashing de contraseñas (entiéndelo junto con la sal)
- Aprende: cómo almacenar contraseñas con seguridad (hashing + sal en la práctica)
- Fundamentos: almacenar contraseñas correctamente