¿Qué es un salt criptográfico y por qué es crucial?
Un salt es un string aleatorio que se combina con una contraseña antes de hashearla. Sin salt, dos usuarios con la misma contraseña tendrían hashes idénticos, lo que permite ataques de rainbow table donde un atacante precomputa hashes de millones de passwords comunes.
Con salt, incluso si dos usuarios usan 'password123', sus hashes son completamente distintos porque cada uno tiene su salt único: hash(password123 + salt_usuario1) ≠ hash(password123 + salt_usuario2). Esto hace inviable precalcular tablas de hashes.
El salt NO necesita ser secreto—se guarda en texto plano junto al hash en tu base de datos. Su función no es ocultar, sino garantizar unicidad. Un salt típico es de 16-32 bytes (128-256 bits) generado con una fuente criptográficamente segura como crypto.randomBytes() en Node o secrets.token_bytes() en Python.
Implementación correcta de salt + hash
Nunca implementes tu propio sistema de hashing. Usá bibliotecas probadas: bcrypt (recomendado para passwords), Argon2 (ganador de competencia PHC 2015), o scrypt. Estas librerías generan el salt automáticamente y lo incluyen en el output.
Ejemplo con bcrypt en Node: bcrypt.hash(password, 12) genera un string como '$2b$12$[salt][hash]'. El '12' es el cost factor (2^12 rondas). Mayor número = más seguro pero más lento. 12-14 es razonable en 2024. No uses SHA-256 directo para passwords—es demasiado rápido y permite brute force masivo.
Al verificar: bcrypt.compare(passwordIngresada, hashGuardado) extrae el salt automáticamente del hash guardado y recomputa. Si coincide, la contraseña es correcta. El salt único por usuario hace que cada verificación sea independiente—comprometer un hash no compromete otros.
Salts en otros contextos de seguridad
Salts también se usan en derivación de claves (KDF), tokens de sesión, y para prevenir timing attacks. En JWT, por ejemplo, un salt aleatorio en el payload hace que tokens con misma data generen firmas distintas, complicando análisis de patrones.
Para tokens de recuperación de password, generá un salt criptográficamente fuerte (32+ bytes), hashealo, guardá el hash en DB, y enviá el salt original por email. Cuando el usuario vuelve con el token, rehasheas y comparás con el guardado. Nunca guardes el token en texto plano en la base.
En cifrado simétrico (AES), los 'initialization vectors' (IV) cumplen función similar al salt: aseguran que el mismo mensaje cifrado con la misma clave produzca ciphertexts distintos. El IV debe ser aleatorio por mensaje y se transmite en claro junto al ciphertext.
Errores comunes con salts y cómo evitarlos
Error 1: Usar el mismo salt para todos los usuarios. Esto anula el beneficio—un atacante puede precomputar hashes para ese salt específico. Solución: salt único por usuario, generado en cada registro.
Error 2: Salts cortos o predecibles. Usar timestamp o user_id como salt es inseguro. Solución: mínimo 128 bits (16 bytes) de randomness criptográfica con fuentes como /dev/urandom o Web Crypto API.
Error 3: Hashear el password y después agregar salt. El orden es password + salt → hash, no hash(password) + salt. La concatenación debe ocurrir antes del hashing. Bcrypt y Argon2 manejan esto correctamente por vos.
Error 4: Re-usar salts en rotación de passwords. Cuando un usuario cambia su contraseña, generá un nuevo salt. No reutilices el anterior—querés que cada hash sea independiente de su historia.