En criptografía , una sal son datos aleatorios que se utilizan como una entrada adicional a una función unidireccional que codifica datos , una contraseña o una frase de contraseña . [1] Las sales se utilizan para proteger las contraseñas almacenadas. Históricamente, solo una función de hash criptográfica de la contraseña se almacenaba en un sistema, pero con el tiempo, se desarrollaron salvaguardas adicionales para proteger contra la identificación de contraseñas comunes o duplicadas (ya que sus hashes son idénticos). [2] La salazón es una de esas protecciones.
Se genera una nueva sal de forma aleatoria para cada contraseña. Normalmente, el salt y la contraseña (o su versión después del estiramiento de la clave ) se concatenan y se alimentan a una función hash criptográfica , y el valor hash de salida (pero no la contraseña original) se almacena con el salt en una base de datos. El hash permite una autenticación posterior sin mantener y, por lo tanto, arriesgar la exposición de la contraseña de texto sin formato si el almacén de datos de autenticación se ve comprometido. Tenga en cuenta que debido a esto, las sales no necesitan encriptarse o almacenarse por separado de la contraseña hash en sí, porque incluso si un atacante tiene acceso a la base de datos con los valores hash y las sales, el uso correcto de dichas sales dificultará el uso común de dichas sales. ataques. [1]
Las sales defienden contra ataques que utilizan tablas precalculadas (por ejemplo, tablas de arco iris ) [3] ya que pueden hacer que el tamaño de la tabla necesario para un ataque exitoso sea prohibitivamente grande sin sobrecargar a los usuarios. Dado que las sales difieren entre sí, también protegen las contraseñas redundantes (p. Ej., De uso común, reutilizadas) ya que se crean diferentes hashes salados para diferentes instancias de la misma contraseña.
Las sales criptográficas se utilizan ampliamente en muchos sistemas informáticos modernos, desde las credenciales del sistema Unix hasta la seguridad de Internet .
Las sales están estrechamente relacionadas con el concepto de nonce criptográfico .
Uso de ejemplo
Aquí hay un ejemplo incompleto de un valor de sal para almacenar contraseñas. Esta primera tabla tiene dos combinaciones de nombre de usuario y contraseña. La contraseña no se almacena.
Nombre de usuario | Contraseña |
---|---|
usuario1 | contraseña123 |
usuario2 | contraseña123 |
El valor de la sal se genera al azar y puede tener cualquier longitud; en este caso, el valor de sal tiene una longitud de 8 bytes . El valor de sal se agrega a la contraseña de texto sin formato y luego el resultado es hash, esto se conoce como el valor hash. Se almacenan tanto el valor de sal como el valor hash.
Nombre de usuario | Valor de sal | Cadena para ser hash | Valor hash = SHA256 (contraseña + valor de sal) |
---|---|---|---|
usuario1 | E1F53135E559C253 | contraseña123 E1F53135E559C253 | 72AE25495A7981C40622D49F9A52E4F1565C90F048F59027BD9C8C8900D5C3D8 |
usuario2 | 84B03D034B409D4E | contraseña123 84B03D034B409D4E | B4B6603ABC670967E99C7E7F1389E40CD16E78AD38EB1468EC2AA1E62B8BED3A |
Como ilustra la tabla anterior, diferentes valores de sal crearán valores hash completamente diferentes, incluso cuando las contraseñas de texto sin formato sean exactamente las mismas. Además, los ataques de diccionario se mitigan hasta cierto punto, ya que un atacante prácticamente no puede calcular previamente los hashes . Sin embargo, una sal no puede proteger contraseñas comunes o fáciles de adivinar.
Errores comunes
Reutilización de sal
Usar la misma sal para todas las contraseñas es peligroso porque una tabla precalculada que simplemente contabiliza la sal inutilizará la sal.
La generación de tablas precalculadas para bases de datos con sales únicas para cada contraseña no es viable debido al costo computacional de hacerlo. Pero, si se usa una sal común para todas las entradas, la creación de dicha tabla (que represente la sal) se convierte en un ataque viable y posiblemente exitoso. [4]
Debido a que la reutilización de sal 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.
Sal corta
Si una sal es demasiado corta, un atacante puede precalcular una tabla de cada sal posible agregada a cada contraseña probable. El uso de una sal larga asegura que dicha mesa sea prohibitivamente grande. [5]
Beneficios
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. Entonces, un atacante podría elegir una cadena, llamarla intento [0] y luego calcular el hash (intento [0]). Un usuario cuyo hash almacenado en el archivo es hash (intento [0]) puede o no tener el intento de contraseña [0]. Sin embargo, incluso si el intento [0] no 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 hash (intento [0] || sal [a]), comparar con la entrada A, luego hash (intentar [0] || sal [b]), comparar con entrada B, y así sucesivamente. Esto evita cualquier intento de descifrar varias contraseñas (solo cuando se evita la reutilización de sal). [6]
Las sales también combaten el uso de tablas precalculadas para descifrar contraseñas. [7] Tal tabla 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 finalización de un conjunto de cadenas de hash precalculadas . En cualquier caso, la salazón puede defenderse del uso de tablas precalculadas al alargar los hash y hacer que se extraigan de conjuntos de caracteres más grandes, lo que hace menos probable que la tabla cubra los hash resultantes. En particular, una tabla precalculada necesitaría cubrir la cadena [salt + hash] en lugar de simplemente [hash].
El moderno de contraseñas ocultas del sistema, en el que los hashes de contraseñas y otros datos de seguridad se almacenan en un archivo que no sea pública, algo mitiga estas preocupaciones. Sin embargo, siguen siendo relevantes en instalaciones de múltiples servidores que utilizan sistemas de administración de contraseñas centralizados para enviar contraseñas o hashes de contraseñas a múltiples sistemas. En tales instalaciones, la cuenta raíz de cada sistema individual puede tratarse como menos confiable que los administradores del sistema de contraseñas centralizado, por lo que sigue siendo útil garantizar que la seguridad del algoritmo hash de contraseñas, incluida la generación de valores de sal únicos, sea adecuado. [ cita requerida ]
Otro beneficio (menor) de un salt es el siguiente: dos usuarios pueden elegir la misma cadena como contraseña, o el mismo usuario puede elegir usar la misma contraseña en dos máquinas. Sin un salt, 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, lo que permite que cualquiera que conozca una de las contraseñas de la cuenta acceda a la otra cuenta. Al agregar la sal a las contraseñas con dos caracteres aleatorios, incluso si dos cuentas usan la misma contraseña, nadie puede descubrir esto simplemente leyendo hashes.
Implementaciones de Unix
Década de 1970-1980
Las versiones anteriores de Unix usaban un archivo de contraseña /etc/passwd
para almacenar los valores hash de las contraseñas saladas (contraseñas con el prefijo sales aleatorias de dos caracteres). En estas versiones anteriores de Unix, la sal también se almacenaba en el archivo passwd (como texto sin cifrar) junto con el hash de la contraseña con sal. El archivo de contraseñas se podía leer públicamente para todos los usuarios del sistema. Esto era necesario para que las herramientas de software con privilegios de usuario pudieran encontrar nombres de usuario y otra información. Por lo tanto, la seguridad de las contraseñas está protegida solo por las funciones unidireccionales (cifrado o hash) utilizadas para tal fin. Las primeras implementaciones de Unix limitaban las contraseñas a ocho caracteres y usaban un salt de 12 bits, lo que permitía 4.096 valores de salt posibles. [8] Este fue un equilibrio apropiado para los costos de computación y almacenamiento de la década de 1970. [9]
Década de 1980
El sistema de contraseña oculta se utiliza para limitar el acceso a hash y sal. La sal tiene ocho caracteres, el hash es 86 caracteres y la longitud de la contraseña es ilimitada.
Implementaciones de aplicaciones web
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 una sal, un ataque de inyección SQL exitoso puede producir contraseñas fáciles de descifrar. 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 las aplicaciones web . [10] En la sección de enlaces externos a continuación se pueden encontrar algunas referencias adicionales sobre el uso de un salt para proteger los hashes de contraseñas en idiomas específicos (PHP, .NET, etc.) .
Ver también
Referencias
- ^ a b "Límite de descarga excedido" . citeseerx.ist.psu.edu . Consultado el 14 de mayo de 2021 .
- ^ Anderson, Ross (2020). Ingeniería de seguridad: una guía para construir sistemas distribuidos confiables (Tercera ed.). Indianápolis, Indiana. ISBN 978-1-119-64281-7. OCLC 1224516855 .
- ^ "Las contraseñas importan" . Consultado el 9 de diciembre de 2016 .
- ^ "Hashing seguro de contraseñas saladas: cómo hacerlo correctamente" . crackstation.net . Consultado el 19 de marzo de 2021 .
- ^ "Hashing seguro de contraseñas saladas: cómo hacerlo correctamente" .
- ^ "Almacenamiento de contraseñas - Serie de hojas de trucos OWASP" . cheatsheetseries.owasp.org . Consultado el 19 de marzo de 2021 .
- ^ "Cómo funcionan las tablas de arco iris" . kestas.kuliukas.com .
- ^ Morris, Robert; Thompson, Ken (3 de abril de 1978). "Seguridad de contraseña: historia de un caso" . Murray Hill, Nueva Jersey, Estados Unidos: Bell Laboratories . Archivado desde el original el 21 de agosto de 2013. Cite journal requiere
|journal=
( ayuda ) - ^ "Cómo Unix Implementa Contraseñas [Libro]" .
- ^ "Diario de ISC - Hashing de contraseñas" . Dshield.org . Consultado el 15 de octubre de 2011 .
enlaces externos
- Wille, Christoph (5 de enero de 2004). "Almacenamiento de contraseñas - ¡hecho bien!" .
- Hoja de trucos criptográficos de OWASP
- cómo cifrar las contraseñas de los usuarios