En criptografía , una sal son datos aleatorios que se alimentan como una entrada adicional a una función unidireccional que codifica datos , una contraseña o frase de contraseña . [1] La salazón ayuda a defenderse contra 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 salazón no supone ninguna carga para los usuarios.
La forma en que normalmente se realiza el salting es generando un nuevo salt aleatoriamente para cada contraseña. El salt y la contraseña (o su versión después de la extensión de la clave ) se concatenan y se envían a una función hash criptográfica , y el valor hash de salida luego se almacena con el salt en una base de datos. No es necesario cifrar la sal, porque conocerla no ayudaría al atacante. [5]
La salazón se utiliza ampliamente en ciberseguridad, desde las credenciales del sistema Unix hasta la seguridad de Internet .
Las sales están relacionadas con los nonces criptográficos .
Sin sal, 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 su lugar, se genera un salt y se agrega a cada contraseña, lo que hace que el hash resultante genere valores diferentes para la misma contraseña original.
Luego, la sal y el hash se almacenan en la base de datos. Para probar posteriormente si la contraseña que ingresa un usuario es correcta, se puede realizar el mismo proceso en ella (agregando el salt de ese usuario a la contraseña y calculando el hash resultante): si el resultado no coincide con el hash almacenado, no podría tener ha sido la contraseña correcta que se ingresó.
En la práctica, un salt generalmente se genera utilizando datos existentes, como la identificación de un usuario. Si en su lugar se crea un salt completamente aleatorio, se almacena en el hash (por ejemplo, anteponiéndolo, añadiéndolo, reemplazando cada enésimo carácter con él, etc.) para que el sistema pueda recuperarlo más tarde.
Usar la misma sal para todas las contraseñas es peligroso porque una tabla precalculada que simplemente tiene en cuenta la sal la inutilizará.
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, crear 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 salt puede hacer que los usuarios con la misma contraseña tengan el mismo hash, descifrar un solo hash puede hacer que otras contraseñas también se vean comprometidas.
Si un salt es demasiado corto, un atacante puede precalcular una tabla de cada salt posible adjunto a cada contraseña probable. El uso de una sal larga garantiza que una mesa de este tipo sea prohibitivamente grande. [7] [8]
Para comprender la diferencia entre descifrar una sola contraseña y un conjunto de ellas, considere un archivo con los usuarios y sus contraseñas hash. Digamos que el archivo no tiene sal. Luego, un atacante podría elegir una cadena, llamarla attempt[0]y luego calcularla hash(attempt[0]). Un usuario cuyo hash almacenado en el archivo puede hash(attempt[0])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 las 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 posibilidad de una coincidencia aumenta con la cantidad 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 varias contraseñas, dado que se evita la reutilización de salt. [9]hash(attempt[0] || salt[a])hash(attempt[0] || salt[b])
Salts también combate el uso de tablas precalculadas para descifrar contraseñas. [10] Una tabla de este tipo podría simplemente asignar 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 hash precalculadas . En cualquier caso, la salazón puede defenderse del uso de tablas precalculadas al alargar los hashes y hacer que se extraigan de conjuntos de caracteres más grandes, lo que hace 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 moderno sistema de contraseñas ocultas , 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 múltiples servidores que utilizan sistemas centralizados de administración de contraseñas para enviar contraseñas o hashes de contraseñas a múltiples sistemas. En tales instalaciones, la cuenta raíz en cada sistema individual puede ser tratada como menos confiable que los administradores del sistema de contraseñas centralizado, por lo que vale la pena garantizar que la seguridad del algoritmo de hash de contraseñas, incluida la generación de valores salt únicos, sea adecuado. [ cita necesaria ]
Otro beneficio (menor) de salt es el siguiente: dos usuarios pueden elegir la misma cadena como contraseña. Sin sal, esta contraseña se almacenaría como la misma cadena hash en el archivo de contraseña. Esto revelaría el hecho de que las dos cuentas tienen la misma contraseña, permitiendo que cualquiera que conozca una de las contraseñas de la cuenta acceda a la otra cuenta. Al agregar dos caracteres aleatorios a las contraseñas, incluso si dos cuentas usan la misma contraseña, nadie puede descubrirlo simplemente leyendo hashes. La salazón también hace que sea extremadamente difícil determinar si una persona ha utilizado la misma contraseña para varios sistemas. [11]
Las versiones anteriores de Unix usaban un archivo de contraseñas /etc/passwd para almacenar los hash de las contraseñas saladas (contraseñas con el prefijo sales aleatorias de dos caracteres). En estas versiones anteriores de Unix, el salt también se almacenaba en el archivo passwd (como texto sin cifrar) junto con el hash de la contraseña saltada. El archivo de contraseña 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 nombres de usuarios 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 tal fin. Las primeras implementaciones de Unix limitaron las contraseñas a ocho caracteres y utilizaron un salt de 12 bits, lo que permitía 4.096 valores salt posibles. [12] Este era un equilibrio apropiado para los costos computacionales y de almacenamiento de la década de 1970. [13]
El sistema de contraseña oculta se utiliza para limitar el acceso a hashes y salt. La sal es de ocho caracteres, el hash es de 86 caracteres y la longitud de la contraseña es efectivamente ilimitada, salvo errores de desbordamiento de pila.
Es común que una aplicación web almacene en una base de datos el valor hash de la contraseña de un usuario. Sin sal, un ataque de inyección SQL exitoso puede generar contraseñas fácilmente descifrables. Debido a que muchos usuarios reutilizan contraseñas para varios sitios, el uso de salt es un componente importante de la seguridad general de las aplicaciones web . [14] Algunas referencias adicionales sobre el uso de salt para proteger hashes de contraseñas en lenguajes o bibliotecas específicos (PHP, bibliotecas .NET, etc.) se pueden encontrar en la sección de enlaces externos a continuación.
{{cite book}}: Mantenimiento CS1: falta el editor de la ubicación ( enlace ){{cite book}}: Mantenimiento CS1: falta el editor de la ubicación ( enlace )