security - password - que es salt en criptografia
Sal no aleatoria para hashes de contraseñas (9)
ACTUALIZACIÓN: Recientemente aprendí de esta pregunta que en toda la discusión a continuación, yo (y estoy seguro de que otros también lo hicieron) era un poco confuso: lo que sigo llamando una tabla de arcoiris, de hecho se llama una tabla hash. Las tablas Rainbow son criaturas más complejas, y en realidad son una variante de Hellman Hash Chains. Aunque creo que la respuesta sigue siendo la misma (ya que no se reduce al criptoanálisis), parte de la discusión podría ser un poco sesgada.
La pregunta: " ¿Qué son las tablas del arco iris y cómo se usan? "
Normalmente, siempre recomiendo usar un valor aleatorio criptográficamente fuerte como sal, para ser utilizado con funciones hash (por ejemplo, para contraseñas), como para proteger contra los ataques de Rainbow Table.
Pero, ¿es realmente criptográficamente necesario que la sal sea aleatoria? ¿Sería suficiente con algún valor único (único por usuario, por ejemplo, userId) en este sentido? De hecho, evitaría usar una sola tabla Rainbow para descifrar todas las contraseñas (o la mayoría) en el sistema ...
Pero, ¿la falta de entropía realmente debilita la fuerza criptográfica de las funciones hash?
Tenga en cuenta que no estoy preguntando por qué usar sal, cómo protegerla (no tiene que ser así), usar un solo hash constante (no hacerlo) o qué tipo de función hash usar.
Solo si la sal necesita entropía o no.
Gracias a todos por las respuestas hasta ahora, pero me gustaría centrarme en las áreas con las que estoy (un poco) menos familiarizado. Principalmente implicaciones para el criptoanálisis: apreciaría mucho si alguien tiene alguna aportación del PoV cripto-matemático.
Además, si hay vectores adicionales que no se han tenido en cuenta, eso también es una gran entrada (vea @Dave Sherohman point en sistemas múltiples).
Más allá de eso, si tiene alguna teoría, idea o práctica recomendada, respalde esto con pruebas, escenarios de ataque o evidencia empírica. O incluso consideraciones válidas para compensaciones aceptables ... Estoy familiarizado con las Mejores Prácticas (capital B mayúscula) sobre el tema, me gustaría probar qué valor proporciona realmente.
EDITAR: Algunas muy buenas respuestas aquí, pero creo que @Dave dice, se trata de tablas de Rainbow para nombres de usuario comunes ... y posibles nombres menos comunes también. Sin embargo, ¿qué pasa si mis nombres de usuario son globalmente únicos? No necesariamente único para mi sistema, sino por cada usuario, por ejemplo, la dirección de correo electrónico.
No habría incentivo para construir un RT para un solo usuario (como @Dave enfatizó, la sal no se mantiene en secreto), y esto aún evitaría la agrupación. El único problema sería que podría tener el mismo correo electrónico y la misma contraseña en un sitio diferente, pero Salt no lo evitaría de todos modos.
Entonces, vuelve al criptoanálisis: ¿es necesaria la entropía o no? (Mi pensamiento actual es que no es necesario desde un punto de vista de criptoanálisis, pero es por otras razones prácticas).
¡La fuerza de una función hash no está determinada por su entrada!
Usar una sal conocida por el atacante obviamente hace que construir una tabla arcoiris (especialmente para nombres de usuario codificados como raíz ) sea más atractivo, pero no debilita el hash . Usar una sal desconocida para el atacante hará que el sistema sea más difícil de atacar.
La concatenación de un nombre de usuario y contraseña podría proporcionar una entrada para una tabla inteligente de arcoíris, por lo que usar una sal de una serie de caracteres pseudoaleatorios, almacenada con la contraseña hash es probablemente una mejor idea. Como ilustración, si tuviera el nombre de usuario "potato" y la contraseña "beer", la entrada concatenada para su hash es "potatobeer", que es una entrada razonable para una tabla rainbow.
Cambiar la sal cada vez que el usuario cambie su contraseña puede ayudar a derrotar ataques prolongados, como lo haría la aplicación de una política de contraseñas razonable, por ejemplo, caso mixto, puntuación, duración mínima, cambio después de n semanas.
Sin embargo, diría que tu elección del algoritmo de resumen es más importante. El uso de SHA-512 va a ser más doloroso para alguien que genera una tabla de arco iris que MD5, por ejemplo.
Es cierto que el nombre de usuario solo puede ser problemático ya que las personas pueden compartir nombres de usuario entre diferentes sitios web. Pero no debería ser problemático si los usuarios tuvieran un nombre diferente en cada sitio web. Entonces, ¿por qué no solo hacerlo único en cada sitio web? Hash la contraseña algo así como esto
hashfunction ("www.yourpage.com /" + username + "/" + password)
Esto deberia resolver el problema. No soy un maestro del criptoanálisis, pero estoy seguro de que el hecho de que no usemos alta entropía haría que el hash sea más débil.
La entropía es el punto del valor de la sal.
Si hay algo de "matemática" simple y reproducible detrás de la sal, entonces es lo mismo que la sal no está allí. Solo agregar valor de tiempo debería estar bien.
La sal debe tener tanta entropía como sea posible para garantizar que, si un valor de entrada determinado se mezcla múltiples veces, el valor hash resultante será, siempre que sea posible, siempre diferente.
Usar valores de sal cambiantes con tanta entropía como sea posible en la sal asegurará que la probabilidad de hash (por ejemplo, contraseña + sal) produzca valores hash completamente diferentes.
Cuanta menos entropía haya en la sal, mayor será la probabilidad de que generes el mismo valor de sal, ya que así tendrás más posibilidades de generar el mismo valor hash.
La naturaleza del valor hash es "constante" cuando se conoce la entrada y "constante" que permite que los ataques del diccionario o las tablas del arco iris sean tan eficaces. Al variar el valor hash resultante tanto como sea posible (usando valores altos de sal de entropía) se asegura que el hash de la misma entrada + sal aleatoria producirá muchos resultados de valores hash diferentes, lo que frustra (o al menos reduce en gran medida la efectividad) de la tabla rainbow ataques.
La sal se almacena tradicionalmente como un prefijo a la contraseña hash. Esto ya lo hace conocido para cualquier atacante con acceso al hash de contraseña. Usar el nombre de usuario como salt o no no afecta ese conocimiento y, por lo tanto, no tendría ningún efecto en la seguridad de un solo sistema.
Sin embargo, usar el nombre de usuario o cualquier otro valor controlado por el usuario como sal reduciría la seguridad entre sistemas, ya que un usuario que tiene el mismo nombre de usuario y contraseña en múltiples sistemas que usan el mismo algoritmo de hash de contraseña terminaría con el mismo hash de contraseña cada uno de esos sistemas. No considero que esto sea una responsabilidad importante porque, como atacante, probaría las contraseñas que se sabe que una cuenta objetivo usó en otros sistemas antes de intentar cualquier otro medio para comprometer la cuenta. Los hash idénticos solo me dirían de antemano que la contraseña conocida funcionaría, no facilitarían el ataque real. (Tenga en cuenta, sin embargo, que una comparación rápida de las bases de datos de la cuenta proporcionaría una lista de objetivos de mayor prioridad, ya que me diría quién es y quién no reutiliza las contraseñas).
El mayor peligro de esta idea es que los nombres de usuario se reutilizan comúnmente: casi cualquier sitio que desee visitar tendrá una cuenta de usuario llamada "Dave", por ejemplo, y "admin" o "raíz" son aún más comunes, lo que haría construcción de tablas de arco iris dirigidas a los usuarios con esos nombres comunes mucho más fácil y más eficaz.
Ambas fallas podrían abordarse de manera efectiva agregando un segundo valor de sal (ya sea fijo y oculto o expuesto como sal estándar) a la contraseña antes de mezclarlo, pero, en ese momento, también podría estar usando sal entrópica estándar de todos modos. de trabajar el nombre de usuario en él.
Editado para agregar: Mucha gente habla de entropía y de si la entropía en la sal es importante. Lo es, pero no por la razón que la mayoría de los comentarios parecen pensar.
El pensamiento general parece ser que la entropía es importante, por lo que la sal será difícil de adivinar para un atacante. Esto es incorrecto y, de hecho, completamente irrelevante. Como varias personas han señalado varias veces, los ataques que se verán afectados por la sal solo pueden ser realizados por alguien con la base de datos de contraseñas y alguien con la base de datos de contraseñas solo puede ver cuál es la sal de cada cuenta. Si es posible o no, no importa cuando puedes buscarlo trivialmente.
La razón por la que la entropía es importante es evitar el agrupamiento de los valores de sal. Si la sal se basa en el nombre de usuario y sabe que la mayoría de los sistemas tendrán una cuenta llamada "raíz" o "administrador", entonces puede crear una tabla de arcoiris para esas dos sales y romperá la mayoría de los sistemas. Si, por otro lado, se usa una sal aleatoria de 16 bits y los valores aleatorios tienen una distribución más o menos pareja, entonces se necesita una tabla arcoiris para todas las 2 ^ 16 sales posibles.
No se trata de evitar que el atacante sepa cuál es la sal de una cuenta individual, se trata de no darles el objetivo grande y gordo de una sola sal que se utilizará en una proporción sustancial de objetivos potenciales.
Me gusta usar ambas: una sal aleatoria de alta entropía por registro, más la identificación única del registro en sí.
Aunque esto no agrega mucho a la seguridad contra ataques de diccionario, etc., elimina el caso marginal donde alguien copia su sal y hash a otro registro con la intención de reemplazar la contraseña con la suya.
(Es cierto que es difícil pensar en una circunstancia en la que esto se aplica, pero no puedo ver ningún daño en los cinturones y llaves cuando se trata de seguridad).
Si la sal es conocida o se puede adivinar fácilmente, no has aumentado la dificultad de un ataque de diccionario. Incluso puede ser posible crear una tabla de arco iris modificada que tenga en cuenta una sal "constante".
El uso de sales únicas aumenta la dificultad de los ataques de diccionario BULK.
Tener un valor único de sal criptográficamente fuerte sería ideal.
Yo diría que siempre que la sal sea diferente para cada contraseña, probablemente estarás bien. El objetivo de la sal es que no se pueda usar una tabla rainbow estándar para resolver cada contraseña en la base de datos. Entonces, si aplica una sal diferente a cada contraseña (incluso si no es aleatoria), el atacante básicamente tendría que calcular una nueva tabla de arcoíris para cada contraseña, ya que cada contraseña usa una sal diferente.
Usar una sal con más entropía no ayuda mucho, porque se supone que el atacante ya tiene la base de datos. Ya que necesita poder recrear el hash, ya debe saber qué es la sal. Así que tienes que almacenar la sal, o los valores que componen la sal en tu archivo de todos modos. En sistemas como Linux, el método para obtener la sal es conocido, por lo que no tiene sentido tener una sal secreta. Debes asumir que el atacante que tiene tus valores de hash, probablemente también conozca tus valores de sal.
Usar una sal de alta entropía es absolutamente necesario para almacenar las contraseñas de forma segura.
Toma mi nombre de usuario ''gs'' y añádelo a mi contraseña ''MiContraseña'' da gsMyPassword. Esto se rompe fácilmente usando una tabla de arcoiris porque si el nombre de usuario no tiene suficiente entropía podría ser que este valor ya esté almacenado en la tabla de arcoiris, especialmente si el nombre de usuario es corto.
Otro problema son los ataques donde sabe que un usuario participa en dos o más servicios. Hay muchos nombres de usuario comunes, probablemente los más importantes son admin y root. Si alguien creara una tabla arco iris que tenga sales con los nombres de usuario más comunes, podría usarlas para comprometer cuentas.
Solían tener una sal de 12 bits . 12 bit son 4096 combinaciones diferentes. Eso no era lo suficientemente seguro porque esa gran cantidad de información se puede almacenar fácilmente hoy en día . Lo mismo aplica para los 4096 nombres de usuario más usados. Es probable que algunos de sus usuarios elijan un nombre de usuario que pertenezca a los nombres de usuario más comunes.
Encontré este comprobador de contraseñas que resuelve la entropía de tu contraseña. Tener una entropía más pequeña en las contraseñas (como mediante el uso de nombres de usuario) hace que sea mucho más fácil para las tablas rainbow, ya que tratan de cubrir al menos todas las contraseñas con baja entropía, porque es más probable que ocurran.