¿Qué es el salting en seguridad? Explicación del hash de contraseñas
En junio de 2012, un atacante filtró 117 millones de registros de cuentas de LinkedIn en un foro ruso. La lista era una avalancha de hashes SHA-1 sin sal. SHA-1 es rápido. Sin una sal que separara las contraseñas idénticas, el mismo hash aparecía miles de veces. En aproximadamente setenta y dos horas, los investigadores de seguridad habían descifrado cerca del noventa por ciento del archivo. Cuando la filtración resurgió en mayo de 2016 como parte de un conjunto de datos de 167 millones de registros, esas credenciales alimentaron campañas de relleno de credenciales durante años.
La medida de defensa que habría minimizado esa brecha —añadir sal a cada contraseña almacenada— ya existía en 1979. Se llama "salting" (o "salting"). No es nueva, ni cara, ni particularmente ingeniosa. Es la diferencia entre que una fuga de datos sea un incidente aislado y que se convierta en el problema de contraseñas de todos durante media década.
La mayoría de los fallos actuales en el almacenamiento de contraseñas siguen teniendo la misma causa raíz: alguien decidió que "usar SHA-256" era suficiente. Este artículo explica qué es el salting, cómo funciona en la práctica, contra qué protege y contra qué no, y qué recomienda OWASP como configuración predeterminada para 2026.
¿Qué es el salting en seguridad y hash de contraseñas?
Resumamos el tema en una sola frase. El salting consiste en añadir datos aleatorios a una contraseña antes de que se aplique el hash. El valor aleatorio —el salt— se genera una vez por cuenta, junto con el hash de la nueva contraseña, se almacena en texto plano junto al hash resultante y se lee en cada inicio de sesión. No es una clave. No es un secreto. No es cifrado. Es un modificador público con una única función: garantizar que, cuando dos usuarios tengan la misma contraseña, nunca compartan la misma contraseña hash almacenada.
El hashing por sí solo es unidireccional. Al aplicar SHA-256 o Argon2id a una contraseña, se obtiene un valor de longitud fija que ningún algoritmo puede revertir. El problema es que "ningún algoritmo" excluye un atajo sencillo: buscar el hash en un diccionario precalculado. El salting elimina ese atajo. Al añadir un valor aleatorio (salt) al proceso de hashing, se genera un hash único para cada usuario, incluso cuando el texto subyacente de su contraseña es idéntico palabra por palabra. Contraseñas comunes como "password" y "qwerty" ya no se superponen en la base de datos. El salting garantiza que la filtración de una fila no revele al atacante información sobre los demás usuarios.
Tres reglas distinguen una clave de seguridad útil de una inútil. Primera regla: cada contraseña tiene su propia clave aleatoria, generada cuando el usuario se registra o restablece su contraseña. Una contraseña con clave reutilizada en varias cuentas no es mucho mejor que una sin clave; el ataque masivo funciona igual. Segunda regla: la clave puede ser pública. Conocer la clave por sí sola no le da al atacante ningún atajo contra la función hash subyacente. Por lo tanto, la clave reside en la base de datos junto al hash, y esa ubicación es adecuada, incluso recomendable. Tercera regla: los valores de la clave provienen de un generador de números pseudoaleatorios criptográficamente seguro. Linux expone uno a través de `getrandom(2)`. Node lo llama `crypto.randomBytes`. La biblioteca estándar de Python lo encapsula en `secrets.token_bytes`. El método no criptográfico `Math.random()` no es adecuado, aunque aparece en código real auditado con mucha más frecuencia de la que debería.
Dos personas que elijan "hunter2" como contraseña deberían obtener dos hashes almacenados completamente diferentes. El salting es lo que hace posible esto. Si se omite el salting, la base de datos no solo filtra los hashes, sino también el gráfico social de quién comparte qué contraseña con quién.
¿Cómo funciona el salting de contraseñas?
El mecanismo se divide en cuatro pasos, y diez años de filtraciones de datos de almacenamiento de contraseñas demuestran que casi todos los fallos se producen porque alguien se saltó uno de ellos.
El primer paso se ejecuta durante el registro. La aplicación solicita a un generador de números pseudoaleatorios criptográficamente seguro (CSPRNG) entre dieciséis y treinta y dos bytes aleatorios. Este es el valor de referencia (salt). La guía de OWASP de 2025 considera dieciséis bytes (128 bits) como el mínimo; Auth0 y varios proveedores de gestores de contraseñas recomiendan treinta y dos. La norma SP 800-63B-4 del NIST establece un mínimo de cuatro bytes, pero advierte que las colisiones relacionadas con el cumpleaños comienzan a aparecer alrededor de los sesenta y cinco mil usuarios con ese tamaño, razón por la cual nadie utiliza cuatro bytes.
El segundo paso combina la clave de cifrado (salt) con la contraseña elegida por el usuario. La concatenación es la forma más común, colocando la clave antes o después de la contraseña. Algunos sistemas utilizan HMAC, tratando la clave como tal, lo que evita algunos problemas de longitud que surgen con la concatenación directa.
El tercer paso procesa la entrada combinada mediante un algoritmo de hash de contraseñas, lo que en los libros de texto de criptografía se denomina función de derivación de clave (KDF). Este es el paso en el que la mayoría de los equipos solían fallar, a menudo recurriendo a un algoritmo de hash genérico y dando por concluido el trabajo. El SHA-256 simple no es adecuado para almacenar contraseñas por sí solo. Una GPU de consumo en 2026 procesa más de cien mil millones de hashes SHA-256 por segundo, por lo que incluso con un salt, el coste por intento en el hash criptográfico sigue siendo insignificante. El salting elimina los vectores de ataque de tablas arcoíris. Sin embargo, por sí solo no ralentiza el descifrado de contraseñas por fuerza bruta. La herramienta adecuada en este caso es una función deliberadamente lenta y que consume mucha memoria: Argon2id es la opción predeterminada preferida por OWASP, siendo scrypt y bcrypt aceptables, y PBKDF2 con un número muy alto de iteraciones permitidas cuando el cumplimiento de FIPS-140 obliga a elegir.
El cuarto paso almacena tanto el hash como la sal. Las bibliotecas modernas gestionan el formato de almacenamiento, por lo que no es necesario administrar la sal almacenada manualmente. Una salida de bcrypt tiene el formato `$2b$12$9f4c8a7b...kQR8YZpL9`: esa única cadena contiene el identificador del algoritmo, el factor de coste, la sal y el valor hash. Argon2id utiliza el formato de cadena PHC análogo, `$argon2id$v=19$m=19456,t=2,p=1$$`. Simplemente escribes esa cadena en una columna de la base de datos y listo. La biblioteca ha hecho todo lo necesario para almacenar contraseñas de forma segura: generó datos aleatorios para la sal, procesó la contraseña con un algoritmo hash lento y empaquetó el resultado para su recuperación.
El inicio de sesión sigue el mismo proceso a la inversa. La aplicación busca el salt y el hash almacenado del usuario, procesa la contraseña introducida con el mismo algoritmo y el mismo salt, y compara el resultado con el hash almacenado mediante una comparación de tiempo constante. El tiempo constante es importante: un simple `==` filtra información sobre la cantidad de bytes coincidentes, lo que ha generado vulnerabilidades reales de ataques de temporización. Utilice `hmac.compare_digest`, `crypto.timingSafeEqual` o la función equivalente de su framework.
Por qué es importante salar: el problema de la mesa arcoíris
Las tablas arcoíris son el ataque específico que se inventó para contrarrestar el salting. Imagínese una tabla de búsqueda precalculada que asigna a cada contraseña plausible (cada palabra del diccionario, variación común, entrada de lista filtrada) su hash SHA-256. Estas tablas existen, se venden en foros de cracking y alcanzan tamaños de terabytes. Una vez que un atacante tiene una copia de seguridad de la base de datos con hashes sin sal, buscar un hash en una tabla arcoíris es una consulta a la base de datos, no un ataque de cracking. LinkedIn 2012 siguió exactamente este camino: 117 millones de hashes SHA-1 sin sal contra una tabla arcoíris, el noventa por ciento descifrados en aproximadamente tres días.
Si se añade un valor aleatorio por usuario, las tablas arcoíris dejan de funcionar. El atacante necesitaría una tabla precalculada independiente para cada valor aleatorio único. Con un valor aleatorio de dieciséis bytes, esto implicaría 117 millones de tablas diferentes para 117 millones de usuarios, y cada tabla seguiría ocupando terabytes. Los costes de almacenamiento por sí solos hacen que esto sea inviable. El ataque queda descartado del modelo de amenazas.
Esa es la función principal de la sal. Su especificidad es intencionada. El uso de sal no ralentiza un intento de fuerza bruta contra un usuario concreto. Tampoco impide el relleno de credenciales tras una filtración anterior. La sal no sirve de nada si la contraseña es "123456": el atacante prueba con el diccionario obvio, y la sal se recalcula con cada intento, pero el coste por intento no varía significativamente.
Lo que el salting mitiga de forma fiable: las tablas arcoíris y la filtración de información sobre la reutilización de contraseñas entre usuarios de la misma base de datos. Lo que mitiga el hash lento: el coste por intento. Lo que mitiga el pepper: el robo exclusivo de la base de datos. Lo que mitiga la MFA: el relleno de credenciales. El salting es una capa de seguridad en una pila; añadir un salt para dificultar el descifrado de contraseñas no es lo mismo que hacer que cada contraseña sea difícil de adivinar individualmente. El objetivo del salting es un hash diferente para cada usuario; hacer que cada intento sea costoso es un problema aparte.
Hashing vs cifrado vs salting
Tres términos que suelen generar confusión, especialmente en textos escritos por personas no especializadas. No son intercambiables.
| Cifrado | Hashing | Salazón | |
|---|---|---|---|
| Reversible | Sí, con la llave. | No, por diseño | Modificador, no independiente |
| Longitud de salida | Variable, coincide con la entrada | Fijo (normalmente 256 bits) | N/A — modifica la entrada hash |
| Utilizado para | Confidencialidad de los datos | Integridad, almacenamiento de contraseñas | Fortalecimiento de hashes |
| Se requiere llave | Sí, secreto | No | No, utiliza una sal aleatoria |
El cifrado protege los datos que se desean recuperar posteriormente. El receptor posee la clave, la aplica y lee el original. El hash es unidireccional: una vez que una contraseña se convierte en un hash, ningún algoritmo puede revertirlo. El salting es un modificador que se aplica a la entrada de una función hash; por sí solo, no tiene significado.
La filtración de Adobe en 2013 sirve como ejemplo aleccionador. Adobe almacenó 153 millones de registros de usuarios cifrando las contraseñas con 3DES en modo ECB bajo una única clave para todo el sitio. Esta decisión resultó ser un triple fracaso. El cifrado no es el método adecuado para almacenar contraseñas. El modo ECB filtra entradas idénticas como salidas idénticas. Reutilizar una clave en toda la base de datos implicaba que descifrarla una sola vez descifraba los 153 millones de registros. Schneier la calificó como una de las peores filtraciones de contraseñas de la historia. La solución en cada nivel fue cambiar a un algoritmo de hash lento con sal.
Sal contra pimienta: la defensa de dos capas
La pimienta es el primo menos conocido de la sal. El concepto: un valor secreto adicional, aplicado a cada contraseña que procesa la aplicación, pero almacenado fuera de la base de datos. Puede ser una variable de entorno, una entrada del servicio de gestión de claves o una clave residente en el HSM. La sal se encuentra junto al hash en texto plano. La pimienta no.
El modelo de amenaza se basa en el robo exclusivo de la base de datos. Si un atacante roba únicamente la base de datos —mediante inyección SQL, una copia de seguridad mal configurada o una filtración de datos—, dispone de las claves y los hashes, pero no de la clave secreta global. Sin esta clave, ni siquiera puede iniciar un ataque de fuerza bruta, ya que a cada intento de hash le falta el modificador secreto global.
Una implementación típica ejecuta `argon2id(sal + contraseña + pimienta)` o, con más cuidado, calcula primero `HMAC(pimienta, contraseña + sal)` y pasa el resultado a Argon2id. OWASP recomienda la pimienta para sistemas de alto valor, pero reconoce la desventaja: la rotación de la pimienta es operativamente problemática. Rotarla implica volver a cifrar la contraseña de cada usuario en el siguiente inicio de sesión, y si la pimienta se pierde sin una copia de seguridad, todas las cuentas se vuelven imposibles de verificar. La mayoría de las aplicaciones de consumo omiten la pimienta. Las cargas de trabajo de bancos, gobiernos y atención médica generalmente no la utilizan.
El hash moderno de contraseñas en 2026
La guía de OWASP para el almacenamiento de contraseñas de 2025 clasifica cuatro algoritmos por orden de preferencia. Todos ellos incorporan un valor aleatorio (salt); no es necesario generarlo manualmente.
| Algoritmo | Mínimo de OWASP 2025 | Especulación |
|---|---|---|
| Argon2id (preferido) | m=19 MiB, t=2, p=1 | RFC 9106 (2021) |
| scrypt | N=2^17, r=8, p=1 | RFC 7914 (2016) |
| bcrypt (heredado) | costo ≥ 10; límite de entrada de 72 bytes | Niels Provos, 1999 |
| PBKDF2-HMAC-SHA256 | 600.000 iteraciones | RFC 2898; solo FIPS |
Argon2id requiere mucha memoria, lo que significa que cada intento no solo consume ciclos de CPU, sino también una cantidad definida de RAM. El mínimo de 19 MiB por hash establecido por OWASP implica que un atacante que desarrolle un ASIC personalizado también debe construir una gran cantidad de memoria rápida, y la memoria es el componente más costoso de cualquier equipo. La variante "id" combina Argon2i (resistente a ataques de canal lateral) y Argon2d (resistente a la GPU) ejecutando Argon2i durante la primera mitad y Argon2d durante la segunda.
scrypt es anterior a Argon2id y funciona con el mismo principio de uso intensivo de memoria. bcrypt es aún más antiguo, más simple y tiene un límite estricto de entrada de 72 bytes que a veces causa problemas en aplicaciones que usan contraseñas largas; si necesita entradas más largas, utilice SHA-256 como hash previo y base64 como codificación. PBKDF2 es la opción lenta pero compatible con FIPS; OWASP aumentó su número de iteraciones a 600 000 para SHA-256 en 2023, frente a las 310 000 anteriores.
Lo que no pertenece a esta lista: SHA-256 simple, SHA-512 simple, MD5, SHA-1 y cualquier función personalizada que termine en "+ salt". La velocidad es el criterio de exclusión. SHA-256 fue diseñado para ser rápido en hardware estándar. Eso es lo contrario de lo que necesita el almacenamiento de contraseñas.
Errores comunes de salinización que aparecen en auditorías reales
Los informes de filtraciones de datos reales siguen señalando el mismo puñado de errores.
Reutilizar una misma clave de cifrado para cada usuario invalida todo el mecanismo: el problema de la tabla arcoíris reaparece, solo que con un paso adicional. Usar el nombre de usuario como clave de cifrado es aún peor, ya que los nombres de usuario se repiten en distintos sistemas y las tablas arcoíris se pueden precalcular para los más populares. Las claves de cifrado inferiores a dieciséis bytes empiezan a presentar colisiones en bases de usuarios grandes. Generar claves de cifrado con una función aleatoria no criptográfica —`Math.random()`, `time(0)` mod algo, el generador de números aleatorios predeterminado del lenguaje— produce valores predecibles que anulan la ventaja de usar claves de cifrado.
Un error más sutil consiste en almacenar la sal en un servidor diferente "por seguridad". La sal no es un secreto. Dividirla entre sistemas aumenta la complejidad operativa sin aportar ninguna seguridad criptográfica. Guárdela en la misma fila que el hash. Las cadenas PHC modernas se encargan de esto automáticamente.
El problema más importante, según las auditorías de 2026, es el uso de hash SHA-256 simple con sal y envío de datos. La sal evita las tablas arcoíris. Sin embargo, no soluciona el problema de una granja de GPU que realiza diez mil millones de intentos por segundo contra una sola cuenta. La solución no consiste en añadir una segunda sal, sino en cambiar a una función de derivación de clave (KDF) lenta como Argon2id.
Por último: hashes heredados sin sal. La migración es obligatoria. El procedimiento estándar consiste en verificar el hash heredado en el siguiente inicio de sesión, recalcularlo con el algoritmo moderno y sobrescribirlo. Para los usuarios que no vuelven a iniciar sesión, se debe forzar un restablecimiento de contraseña en un plazo fijo.
Por qué salar solo no es suficiente
El salting es una capa de seguridad, no una fortaleza. Neutraliza un ataque específico —las tablas precalculadas— y no revela nada sobre la fortaleza de la contraseña subyacente. La fuerza bruta sigue funcionando contra contraseñas débiles. El relleno de credenciales sigue funcionando contra contraseñas reutilizadas. El phishing sigue funcionando contra cualquier contraseña.
La seguridad real de las contraseñas en 2026 se basa en cuatro medidas de protección. Argon2id, con un valor aleatorio de dieciséis bytes por usuario, gestiona el almacenamiento. Un valor de seguridad adicional, opcional pero recomendable para sistemas sensibles, bloquea el robo de datos exclusivos de la base de datos. La autenticación multifactor bloquea el relleno de credenciales y la mayoría de los ataques de phishing. La monitorización continua de brechas de seguridad —servicios como Have I Been Pwned y su API— detecta el momento en que las credenciales de un usuario aparecen en una filtración para obligarlo a restablecerlas.
Si se omite cualquiera de esas capas, un atacante acabará encontrando la vulnerabilidad. El salting por sí solo, o cualquier otra medida de seguridad aislada, es precisamente lo que todos los análisis posteriores a brechas de seguridad de la última década han identificado como el punto de fallo.
