Sal no aleatoria para hashes de contraseñas
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 rainbow, de hecho se llama una tabla hash. Las mesas Rainbow son criaturas más complejas, y en realidad son una variante de las cadenas Hash Hellman. 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 mesas arco iris y cómo se utilizan?"
Normalmente, siempre recomiendo usar un valor aleatorio criptográficamente fuerte como salt, para ser utilizado con funciones hash (por ejemplo, para contraseñas), como para proteger contra ataques de tablas Rainbow.
Pero, ¿es realmente necesario criptográficamente que la sal sea aleatoria? ¿Bastaría algún valor único (único por usuario, por ejemplo, userId) a este respecto? De hecho, evitaría el uso de una sola tabla de arco iris para romper todos (o la mayoría) contraseñas 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 salt, cómo protegerlo (no tiene que serlo), usar un único hash constante (no), 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 criptoanálisis-Apreciaría más si alguien tiene alguna entrada del PoV cripto-matemático.
Además, si hay vectores adicionales que no se habían considerado, eso también es una gran entrada (vea el punto @Dave Sherohman en múltiples sistemas).
Más allá de eso, si tiene alguna teoría, idea o mejor práctica, 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 capital P) en el tema, me gustaría probar el valor que esto realmente proporciona.
EDITAR: Algunas respuestas realmente buenas aquí, pero creo que como dice @Dave, se reduce a Tablas de Arco Iris para nombres de usuario comunes... y posibles nombres menos comunes también. Sin embargo, ¿qué pasa si mis nombres de usuario son únicos a nivel mundial? No necesariamente único para mi sistema , pero por cada usuario-por ejemplo, dirección de correo electrónico.
No habría ningún incentivo para construir un RT para un solo usuario( como enfatizó @Dave, la sal no se mantiene en secreto), y esto aún así evitaría la agrupación. El único problema sería que podría tener el mismo correo electrónico y contraseña en un sitio diferente, pero salt no lo impediría de todos modos.
Por lo tanto, se reduce a criptoanálisis - ES la entropía necesaria, o no? (Mi pensamiento actual es que no es necesario desde el punto de vista del criptoanálisis, pero lo es por otras razones prácticas.)
9 answers
Salt se almacena tradicionalmente como un prefijo a la contraseña con hash. Esto ya lo hace saber a 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 salt reduciría la seguridad entre sistemas, como un usuario que tenía el mismo nombre de usuario y contraseña en varios sistemas que usan la misma contraseña el algoritmo de hash terminaría con el mismo hash de contraseña en cada uno de esos sistemas. No considero esto una responsabilidad significativa porque yo, como atacante, intentaría contraseñas que se sabe que una cuenta de destino ha utilizado en otros sistemas primero antes de intentar cualquier otro medio de comprometer la cuenta. Hashes idénticos solo me dirían de antemano que la contraseña conocida funcionaría, no harían el ataque real más fácil. (Tenga en cuenta, sin embargo, que una comparación rápida de la cuenta las bases de datos proporcionarían una lista de objetivos de mayor prioridad, ya que me dirían quién está reutilizando contraseñas y quién no.)
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 "root" son aún más comunes, lo que haría que la construcción de tablas rainbow dirigidas a los usuarios con esos nombres comunes sea mucho más fácil y efectiva.
Ambos defectos se podría abordar 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 hash, pero, en ese punto, también puede estar usando sal entrópica estándar de todos modos en lugar de trabajar el nombre de usuario en ella.
Editado para añadir: Mucha gente está hablando de entropía y si la entropía en la sal es importante. Lo es, pero no por la razón que la mayoría de los comentarios al respecto parecen pensar.
El pensamiento general parece ser que la entropía es importante para que la sal sea difícil de adivinar para un atacante. Esto es incorrecto y, de hecho, completamente irrelevante. Como ha sido señalado varias veces por varias personas, los ataques que se verán afectados por salt 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 mirar para ver cuál es la sal de cada cuenta. Si es adivinable o no, no importa cuando pueda buscarlo trivialmente.
La razón que la entropía es importante es evitar la agrupación de los valores de sal. Si la sal se basa en el nombre de usuario y sabes que la mayoría de los sistemas tendrán una cuenta llamada "root" o "admin", entonces puedes hacer una tabla rainbow 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 uniforme, entonces necesita una tabla de arco iris para todas las 2^16 sales posibles.
No se trata de evitar que el atacante sepa lo que 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.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-02-11 23:06:34
El uso de una sal de alta entropía es absolutamente necesario para almacenar contraseñas de forma segura.
Tome mi nombre de usuario 'gs' y añádalo a mi contraseña 'MyPassword' da gsMyPassword. Esto se rompe fácilmente usando una tabla rainbow porque si el nombre de usuario no tiene suficiente entropía podría ser que este valor ya esté almacenado en la tabla rainbow, especialmente si el nombre de usuario es corto.
Otro problema son los ataques en los que se sabe que un usuario participa en dos o más servicios. Alli son muchos nombres de usuario comunes, probablemente los más importantes son admin y root. Si alguien creó una tabla arcoíris que tiene sales con los nombres de usuario más comunes, podría usarlos para comprometer cuentas.
Solían tener una sal de 12 bits . 12 bits son 4096 combinaciones diferentes. Eso no era lo suficientemente seguro porque esa cantidad de información se puede almacenar fácilmente hoy en día. Lo mismo se aplica a los 4096 nombres de usuario más utilizados. Es probable que algunos de sus usuarios elija un nombre de usuario que pertenezca a los nombres de usuario más comunes.
He encontrado este password checker que resuelve la entropía de tu contraseña. Tener una entropía más pequeña en las contraseñas (como usar nombres de usuario) hace que sea mucho más fácil para rainbowtables, ya que intentan cubrir al menos todas las contraseñas con baja entropía, porque es más probable que ocurran.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-02-19 20:27:14
Es cierto que el nombre de usuario por sí solo puede ser problemático ya que las personas pueden compartir nombres de usuario entre diferentes sitios web. Pero debería ser bastante sencillo si los usuarios tuvieran un nombre diferente en cada sitio web. Entonces, ¿por qué no hacerlo único en cada sitio web? Hash la contraseña algo así como esto
Función hash("www.yourpage.com/"+nombre de usuario+" / " + contraseña)
Esto debería resolver el problema. No soy un maestro del criptoanálisis, pero dudo que el hecho de que no usamos alta entropía haría el hachís más débil.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-10-26 17:18:18
Me gusta usar ambos: una sal aleatoria de alta entropía por registro, más el ID único del registro en sí.
Aunque esto no añade 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 propia.
(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 los frenos cuando se trata de seguridad.)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-02-11 13:34:18
Si la sal es conocida o fácil de adivinar, no ha aumentado la dificultad de un ataque de diccionario. Incluso puede ser posible crear una tabla rainbow modificada que tenga en cuenta una sal" constante".
El uso de sales únicas aumenta la dificultad de los ataques de diccionario MASIVOS.
Tener un valor de sal único y criptográficamente fuerte sería ideal.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-02-11 13:21:57
Yo diría que mientras la sal sea diferente para cada contraseña, probablemente estará bien. El punto de la sal es que no puede usar la tabla estándar rainbow para resolver todas las contraseñas en la base de datos. Entonces, si aplicas una sal diferente a cada contraseña (incluso si no es aleatoria), el atacante básicamente tendría que calcular una nueva tabla rainbow 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 en este caso, se supone que el atacante ya tiene la base de datos. Ya que necesitas ser capaz de recrear el hachís, tienes que saber ya lo que es la sal. Así que tienes que almacenar la sal, o los valores que componen la sal en su 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. Tienes que asumir que el atacante que tiene tus valores hash, probablemente también conoce tus valores salt.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-02-11 13:51:40
La fuerza de una función hash no está determinada por su entrada!
Usar una sal que es conocida por el atacante obviamente hace que construir una tabla rainbow (particularmente para nombres de usuario codificados como root) sea más atractivo, pero no debilita el hash . El uso de una sal que es 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 aún puede proporcionar una entrada para una tabla inteligente rainbow, por lo que usar una sal de una serie de caracteres pseudo-aleatorios, almacenados con la contraseña hash es probablemente una mejor idea. Como ejemplo, si tuviera el nombre de usuario " potato "y la contraseña" cerveza", la entrada concatenada para tu hash es" potatobeer", que es una entrada razonable para una tabla rainbow.
Cambiar la sal cada vez que el usuario cambia su contraseña podría ayudar a derrotar ataques prolongados, al igual que la aplicación de una política de contraseñas razonable, por ejemplo, mayúsculas y minúsculas, puntuación, duración mínima, cambiar después de n semanas.
Sin embargo, yo diría que su elección del algoritmo digest es más importante. El uso de SHA - 512 va a resultar más molesto para alguien que genera una tabla rainbow que MD5, por ejemplo.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-02-11 14:58:56
Salt debe tener tanta entropía como sea posible para asegurar que si un valor de entrada dado se hash varias veces, el valor hash resultante será, lo más cercano posible, siempre diferente.
El uso de valores de sal siempre cambiantes con tanta entropía como sea posible en el salt asegurará que la probabilidad de hashing (por ejemplo, contraseña + salt) producirá valores de hash completamente diferentes.
Cuanto menos entropía haya en la sal, más posibilidades tendrá de generar la misma sal valor, ya que por lo tanto, más posibilidades tienes de generar el mismo valor hash.
Es la naturaleza del valor hash siendo "constante" cuando la entrada es conocida y "constante" lo que permite que los ataques de diccionario o las tablas rainbow sean tan efectivos. Al variar el valor de hash resultante tanto como sea posible (mediante el uso de valores de sal de alta entropía) garantiza que el hash de la misma entrada + sal aleatoria producirá muchos resultados de valor de hash diferentes, derrotando (o al menos reduciendo en gran medida la efectividad de) ataques de mesa arco iris.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-02-11 13:06:36
La entropía es el punto del valor de Sal.
Si hay alguna "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.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-02-11 12:40:59