En criptografía , una sal son datos aleatorios que se introducen como entrada adicional en una función unidireccional que convierte en hash datos , una contraseña o frase de contraseña . [1] La sal ayuda a defenderse de ataques que utilizan tablas precalculadas (por ejemplo, tablas arcoíris ), al aumentar enormemente el tamaño de la tabla necesaria para un ataque exitoso. [2] [3] [4] También ayuda a proteger las contraseñas que aparecen varias veces en una base de datos, ya que se utiliza una nueva sal para cada instancia de contraseña. [5] Además, la sal no supone ninguna carga para los usuarios.
Por lo general, se genera aleatoriamente una sal única para cada contraseña. La sal y la contraseña (o su versión después de la ampliación de la clave ) se concatenan y se envían a una función hash criptográfica , y el valor hash de salida se almacena con la sal en una base de datos. No es necesario cifrar la sal, porque conocerla no ayudaría al atacante. [5]
El uso del salting se extiende a la ciberseguridad, desde las credenciales del sistema Unix hasta la seguridad de Internet .
Las sales están relacionadas con los nonces criptográficos .
Sin una sal, las contraseñas idénticas se asignarán a valores hash idénticos, lo que podría facilitar que un pirata informático adivine las contraseñas a partir de su valor hash.
En lugar de ello, se genera una sal y se añade a cada contraseña, lo que hace que el hash resultante genere valores diferentes para la misma contraseña original.
La sal y el hash se almacenan en la base de datos. Para comprobar más adelante si la contraseña introducida por un usuario es correcta, se puede realizar el mismo proceso (añadiendo la sal de ese usuario a la contraseña y calculando el hash resultante): si el resultado no coincide con el hash almacenado, es posible que la contraseña introducida no haya sido la correcta.
En la práctica, una sal se genera generalmente utilizando un generador de números aleatorios criptográficamente seguro. Los CSPRNG están diseñados para producir números aleatorios impredecibles que pueden ser alfanuméricos. Si bien generalmente no se recomiendan debido a la menor seguridad, algunos sistemas utilizan marcas de tiempo o contadores simples como fuente de sal. A veces, una sal se puede generar combinando un valor aleatorio con información adicional, como una marca de tiempo o datos específicos del usuario, para garantizar la unicidad en diferentes sistemas o períodos de tiempo.
Usar la misma sal para todas las contraseñas es peligroso porque una tabla precalculada que simplemente tiene en cuenta la sal hará que ésta sea inútil.
La generación de tablas precalculadas para bases de datos con sales únicas para cada contraseña no es viable debido al costo computacional que implica hacerlo. Pero, si se utiliza una sal común para todas las entradas, la creación de una tabla de este tipo (que tenga en cuenta la sal) se convierte en un ataque viable y posiblemente exitoso. [6]
Debido a que la reutilización de sal puede provocar que los usuarios con la misma contraseña tengan el mismo hash, descifrar un solo hash puede provocar que otras contraseñas también se vean comprometidas.
Si una sal es demasiado corta, un atacante puede calcular previamente una tabla de todas las posibles sales agregadas a cada contraseña probable. El uso de una sal larga garantiza que dicha tabla sea prohibitivamente grande. [7] [8] 16 bytes (128 bits) o más generalmente son suficientes para proporcionar un espacio lo suficientemente grande de valores posibles, lo que minimiza el riesgo de colisiones (es decir, dos contraseñas diferentes que terminan con la misma sal).
Para entender la diferencia entre descifrar una sola contraseña y un conjunto de ellas, considere un archivo con usuarios y sus contraseñas en hash. Digamos que el archivo no tiene sal. Entonces un atacante podría elegir una cadena, llamarla attempt[0]y luego calcular hash(attempt[0]). Un usuario cuyo hash almacenado en el archivo es hash(attempt[0])puede tener o no contraseña attempt[0]. Sin embargo, incluso si noattempt[0] es la contraseña real del usuario, se aceptará como si lo fuera, porque el sistema solo puede verificar contraseñas calculando el hash de la contraseña ingresada y comparándolo con el hash almacenado en el archivo. Por lo tanto, cada coincidencia descifra una contraseña de usuario y la probabilidad de una coincidencia aumenta con el número de contraseñas en el archivo. Por el contrario, si se utilizan sales, el atacante tendría que calcular , comparar con la entrada A, luego , comparar con la entrada B, y así sucesivamente. Esto evita que cualquier intento de descifrar múltiples contraseñas, dado que se evita la reutilización de la sal. [9]hash(attempt[0] || salt[a])hash(attempt[0] || salt[b])
Las sales también combaten el uso de tablas precalculadas para descifrar contraseñas. [10] Una tabla de este tipo podría simplemente mapear contraseñas comunes a sus hashes, o podría hacer algo más complejo, como almacenar los puntos de inicio y fin de un conjunto de cadenas de hashes precalculadas . En cualquier caso, el salting puede defenderse contra el uso de tablas precalculadas alargando los hashes y haciendo que extraigan de conjuntos de caracteres más grandes, haciendo menos probable que la tabla cubra los hashes resultantes. En particular, una tabla precalculada necesitaría cubrir la cadena [salt + hash]en lugar de simplemente [hash].
El sistema de contraseñas en la sombra moderno , en el que los hashes de contraseñas y otros datos de seguridad se almacenan en un archivo no público, mitiga en cierta medida estas preocupaciones. Sin embargo, siguen siendo relevantes en instalaciones de varios servidores que utilizan sistemas de gestión de contraseñas centralizados para enviar contraseñas o hashes de contraseñas a varios sistemas. En dichas instalaciones, la cuenta raíz de cada sistema individual puede ser tratada como menos confiable que los administradores del sistema de contraseñas centralizado, por lo que sigue siendo conveniente garantizar que la seguridad del algoritmo de hashes de contraseñas, incluida la generación de valores de sal únicos, sea adecuada. [ cita requerida ]
Otro beneficio (menor) de una sal es el siguiente: dos usuarios pueden elegir la misma cadena como contraseña. Sin una sal, esta contraseña se almacenaría como la misma cadena hash en el archivo de contraseñas. Esto revelaría el hecho de que las dos cuentas tienen la misma contraseña, lo que permitiría que cualquiera que conozca la contraseña de una de las cuentas acceda a la otra cuenta. Al agregar sal a las contraseñas con dos caracteres aleatorios, incluso si dos cuentas usan la misma contraseña, nadie puede descubrirlo simplemente leyendo los hashes. El uso de sal también hace que sea extremadamente difícil determinar si una persona ha usado la misma contraseña para varios sistemas. [11]
Las versiones anteriores de Unix utilizaban un archivo de contraseñas /etc/passwd para almacenar los hashes de las contraseñas con sal (contraseñas prefijadas con dos caracteres de sal al azar). En estas versiones anteriores de Unix, la sal también se almacenaba en el archivo passwd (como texto sin formato) junto con el hash de la contraseña con sal. El archivo de contraseñas era de lectura pública para todos los usuarios del sistema. Esto era necesario para que las herramientas de software con privilegios de usuario pudieran encontrar los nombres de usuario y otra información. Por lo tanto, la seguridad de las contraseñas está protegida únicamente por las funciones unidireccionales (cifrado o hash) utilizadas para este propósito. Las primeras implementaciones de Unix limitaban las contraseñas a ocho caracteres y utilizaban una sal de 12 bits, lo que permitía 4096 posibles valores de sal. [12] Este era un equilibrio adecuado para los costos computacionales y de almacenamiento de la década de 1970. [13]
El sistema de contraseñas ocultas se utiliza para limitar el acceso a los hashes y a la sal. La sal tiene ocho caracteres, el hash tiene 86 caracteres y la longitud de la contraseña es prácticamente ilimitada, salvo errores de desbordamiento de pila.
Es habitual que una aplicación web almacene en una base de datos el valor hash de la contraseña de un usuario. Sin una sal, un ataque de inyección SQL exitoso puede dar lugar a contraseñas fácilmente descifrables. Debido a que muchos usuarios reutilizan contraseñas para varios sitios, el uso de una sal es un componente importante de la seguridad general de la aplicación web . [14] Se pueden encontrar algunas referencias adicionales para usar una sal para proteger los hashes de contraseñas en lenguajes o bibliotecas específicos (PHP, las bibliotecas .NET, etc.) en la sección de enlaces externos a continuación.
{{cite book}}: Mantenimiento de CS1: falta la ubicación del editor ( enlace ){{cite book}}: Mantenimiento de CS1: falta la ubicación del editor ( enlace )