stringtranslate.com

Sal (criptografía)

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 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 está muy extendido en el ámbito de la ciberseguridad, desde las credenciales de sistemas Unix hasta la seguridad de Internet .

Las sales están relacionadas con los nonces criptográficos .

Ejemplo

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 pseudoaleatorios 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.

Errores comunes

Reutilización de sal

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.

Longitud de sal

Si una sal es demasiado corta, un atacante puede calcular previamente una tabla de cada sal posible adjunta 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 son generalmente 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).

Beneficios

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]

Implementaciones de Unix

Década de 1970 y 1980

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]

Década de 1980-presente

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.

Implementaciones de aplicaciones web

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.

Véase también

Referencias

  1. ^ Fenton, James L.; Grassi, Paul A.; Garcia, Michael E. (junio de 2017). "Publicación especial 800-63-3 del NIST" (PDF) . Publicaciones de la serie técnica del NIST .
  2. ^ Anderson, Ross (2020). Ingeniería de seguridad: una guía para construir sistemas distribuidos confiables (tercera edición). Indianápolis, Indiana. ISBN 978-1-119-64281-7.OCLC 1224516855  .{{cite book}}: Mantenimiento de CS1: falta la ubicación del editor ( enlace )
  3. ^ Godwin, Anthony (10 de septiembre de 2021). "Las contraseñas importan". The Bug Charmer (Blog) . Consultado el 9 de diciembre de 2016 .
  4. ^ Boneh, Dan; Shoup, Victor (4 de enero de 2020). Un curso de posgrado en criptografía aplicada (PDF) . págs. 693–695.
  5. ^ ab Rosulek, Mike (3 de enero de 2021). "Capítulo 11: Funciones hash" (PDF) . The Joy of Cryptography . págs. 204-205.
  6. ^ "Hash seguro de contraseñas con sal: cómo hacerlo correctamente". crackstation.net . Consultado el 19 de marzo de 2021 .
  7. ^ Menezes, Alfred J.; Oorschot, Paul C. van; Vanstone, Scott A. (1997). Manual de criptografía aplicada . CRC Press. pág. 288. ISBN 0-8493-8523-7.
  8. ^ "Hash seguro de contraseñas con sal: cómo hacerlo correctamente".
  9. ^ "Almacenamiento de contraseñas - Serie de hojas de referencia de OWASP". cheatsheetseries.owasp.org . Consultado el 19 de marzo de 2021 .
  10. ^ "Cómo funcionan las Tablas Arcoíris". kestas.kuliukas.com .
  11. ^ Stallings, William; Lawrie Brown (2015). Seguridad informática: principios y práctica (tercera edición). Boston. ISBN 978-0-13-377392-7.OCLC 874734678  .{{cite book}}: Mantenimiento de CS1: falta la ubicación del editor ( enlace )
  12. ^ Morris, Robert; Thompson, Ken (3 de abril de 1978). "Seguridad de contraseñas: un caso clínico". Bell Laboratories . Archivado desde el original el 21 de agosto de 2013.
  13. ^ Simson Garfinkel; Gene Spafford; Alan Schwartz (2003). "Cómo Unix implementa contraseñas". Practical UNIX and Internet Security (3.ª ed.). O'Reilly Media. ISBN 9780596003234.
  14. ^ "ISC Diary – Hashing Passwords" (Diario de ISC: Hashing de contraseñas). Dshield.org . Consultado el 15 de octubre de 2011 .

Enlaces externos