¿Por qué está bien que una sal no se mantenga en secreto? —Anónimo.
- Porque el secreto es la contraseña; incluso si uno conoce la sal, necesitaría calcular el hash para todas las contraseñas posibles; conocer la sal simplemente reduce el problema de encontrar los hashes de todas las contraseñas posibles multiplicados por todas las sales posibles, a todas las contraseñas posibles, que es el número habitual. -- maru (discusión) contribuciones 01:31, 22 de marzo de 2006 (UTC) [ responder ]
- Pero eso parece una gran ayuda, ¿no? Quiero decir, si la sal se mantuviera en secreto , el espacio de búsqueda sería mucho mayor... ¿O me estoy perdiendo algo? Si conoces la sal de un usuario específico y estás intentando realizar un ataque de diccionario solo contra esa contraseña, la sal no te retrasa mucho. Sin embargo, entiendo que los ataques a gran escala contra todos los usuarios se retrasan. 201.216.245.25 ( discusión ) 15:29, 14 de diciembre de 2009 (UTC) [ responder ]
- Bueno, en primer lugar deberías mantener el hash en secreto. Si el hash se filtra, es probable que también se filtren las sales, a menos que uses algún extraño sistema de base de datos dividida. Por eso no tiene mucho sentido mantener las sales en secreto. Si quieres dificultar un ataque de diccionario, puedes usar más iteraciones y algo como bCrypt, pero esto también te costará muchos recursos (cuantos más recursos sacrifiques, más trabajo tendrá el atacante en teoría). Xhunterx ( discusión ) 17:28 2 enero 2017 (UTC) [ responder ]
- La sección Estadísticas de contraseñas de este artículo: Blogs.forbes.com: Discusión sobre la filtración de datos de Gawker con el fundador Nick Denton fue escrita sólo dos días después de la filtración y dice que la gente ya había descubierto 400.000 de 1,3 millones de contraseñas. Parte de esto se debió al uso de un algoritmo hash más antiguo, pero creo que se podría haber descubierto una cantidad significativa observando la frecuencia de varios hashes y comparando los hashes de contraseñas más comunes con las peores contraseñas (las más comunes): secuencias de números que comienzan con 1 y la palabra "contraseña". Apostaría a que la mayoría de las personas que usan las peores contraseñas también usan la misma contraseña para todos los sitios, lo que hace que esas pocas cuentas fácilmente comprometidas sean aún más valiosas para los piratas informáticos. Incluso unos pocos fragmentos de sal específica del usuario en texto plano evitarían lo que yo llamaría un ataque de popularidad de contraseñas incorrectas. -- GlenPeterson ( discusión ) 13:48, 29 de diciembre de 2010 (UTC) [ responder ]
¿Es un ataque de texto plano conocido efectivo contra funciones hash como SHA-256? Si es así, existe un equilibrio en el que una sal conocida más larga debilita la criptografía, pero una sal más corta aún impide la identificación de contraseñas obviamente similares (consulte mi comentario sobre el ataque de la popularidad de las contraseñas incorrectas) más arriba. El artículo sobre el "texto plano conocido" dice que "los cifrados modernos como el Estándar de cifrado avanzado no son susceptibles a los ataques de texto plano conocido", pero no menciona SHA. No estoy seguro de entender completamente el artículo sobre el ataque Preimage , pero creo que significa que las funciones hash están diseñadas para resistir esta forma de ataque, pero las mejores funciones hash son mejores en este sentido. ¿Alguien sabe algo sobre esto? -- GlenPeterson ( discusión ) 13:48, 29 de diciembre de 2010 (UTC) [ responder ]
- Por definición, el texto simple conocido no hace nada por los hashes, ya que los hashes (sin hablar de MAC) no utilizan contraseñas. Si tienes el texto simple para un hash, no necesitas descifrarlo. Los ataques de texto simple conocidos solo se aplican al cifrado y posiblemente a MAC muy malos. Xhunterx ( discusión ) 17:38 2 enero 2017 (UTC) [ responder ]
- Xhunterx: Glen se refería a cuando el atacante conoce la mayor parte del texto sin formato, como en una sal conocida desde hace mucho tiempo concatenada con una contraseña desconocida más corta y luego codificada (o si es cifrado: cifrado con alguna clave). Para los hashes modernos eso no es un problema. Para los cifrados débiles eso sería un gran problema, ya que el texto sin formato conocido desde hace mucho tiempo permitiría al atacante averiguar la clave, y luego podría descifrar la última parte que llevaba la contraseña como carga de datos cifrados. Para los cifrados modernos bien construidos utilizados correctamente en un buen modo de bloque (modo CTR), y con un buen vector de inicialización , y una clave lo suficientemente fuerte, y así sucesivamente, no es un problema. Ya que para ellos no se puede averiguar la clave, incluso si se conoce la mayor parte (o la totalidad) del texto sin formato, e incluso si el texto sin formato es muy largo.
- @ GlenPeterson : Respuesta corta: No. Las sales más largas no facilitarían la identificación de las contraseñas. Las sales más largas (entrada más larga) no filtran más datos al hacer hash. En realidad, lo opuesto, la entrada más larga provoca una mejor mezcla (más rondas) en la función hash, excepto en el último bloque introducido que todavía solo obtiene una ronda de mezcla. (Mientras que una entrada más larga puede filtrar más datos en otros tipos de criptografía).
- Respuesta larga: Entiendo lo que querías decir. Para los fines de este debate, tenemos dos casos principales: o bien se utiliza la misma sal para todas las contraseñas del archivo de contraseñas, o bien se utilizan diferentes sales para cada contraseña.
- Supongo que aquí estamos hablando de los hashes criptográficos regulares que se mezclan completamente en un bloque a la vez en su estado interno, cuando procesan los datos: consulte la construcción de Merkle-Damgård .
- Caso 1: Si estamos haciendo un hash (sal + contraseña), "+" significa concatenación, y usamos la misma sal para todas las contraseñas, y el atacante conoce la sal y la suma hash resultante, pero no la contraseña, ¿entonces una sal mucho más larga hace que sea más fácil adivinar la contraseña a partir de la sal y la suma hash conocidas? Dado que entonces el atacante conoce más de la entrada a la función hash.
- Creo que eso no facilitaría el ataque. Dado que los hashes criptográficos modernos tienen un efecto de avalancha completo y, hasta donde sabemos, no se pueden calcular al revés (creemos/esperamos que sean unidireccionales). Entonces, una vez que la función hash mezcla el siguiente bloque, oculta completamente lo que vino antes, por lo que una sal que sea más larga que la longitud de un bloque de la función hash no se filtra ni proporciona ninguna información adicional. Además, cuando la función hash mezcla el último bloque con la contraseña, oculta completamente lo que vino antes, siempre que la contraseña sea lo suficientemente buena. Aunque, en este caso, sabemos lo que vino antes porque conocemos la sal. Pero el último bloque se mezcla más que lo suficientemente bien. Pero incluso si son dos contraseñas simples y similares, digamos "test1" y "test2", entonces las sumas de hash se verían totalmente diferentes debido al efecto de avalancha. Entonces, incluso si forzara la contraseña "test1", eso no lo ayudaría a encontrar la contraseña "test2" entre todas las demás sumas de hash en el archivo de contraseñas.
- Si el sistema está haciendo un hash de la contraseña y la sal en otro orden, por ejemplo, hash( contraseña + sal ) o hash( sal + contraseña + sal), o incluso hash( contraseña + sal + contraseña ) (algo así como HMAC ), entonces tener sales más largas no facilitaría el reconocimiento de hashes de contraseñas similares. Dado que una vez que se mezcla la contraseña, el estado interno del hash se verá completamente diferente para "test1" y "test2", luego en el siguiente bloque donde se mezcla la sal final, la suma del hash resultante seguirá siendo totalmente diferente ya que los dos estados internos eran diferentes antes del último bloque. En teoría, este caso protege la contraseña aún mejor, ya que la sal larga provocará más rondas de mezcla después de que se procese la contraseña.
- Caso 2: El otro caso al que te podrías haber referido es si tenemos diferentes sales para cada cuenta. Como hash( salt1 + "test1") y hash( salt2 + "test2"). Eso todavía no ayudaría al atacante a comparar esas sumas de hash o a averiguar una de las contraseñas, incluso si la sal es muy larga, ya que nuevamente: Las sales más largas no filtran más información ya que el efecto de avalancha y la unidireccionalidad ocultan qué datos se introdujeron al principio en la función hash. Y el último bloque se mezcla más que bien. Pero también en este caso, poner la sal al final, haciendo hash( "test1" + salt1), en teoría parece más fuerte.
- Por supuesto, hacer que la función hash tome una ronda adicional no hace daño (como lo hace HMAC ), probablemente protege contra muchas de las debilidades futuras (si las hay) que se encuentran en la función hash. (HMAC fue diseñado para proteger contra una debilidad conocida ( ataque de extensión de longitud ) en la mayoría de las funciones hash criptográficas actuales, pero esa debilidad no afecta el hash de contraseñas que estamos haciendo aquí). Desafortunadamente, simplemente causar rondas adicionales no protege contra la debilidad principal que se encuentra en MD5 y SHA-1. La debilidad donde puedes crear a propósito dos textos similares que obtienen la misma suma hash. El MD5 y SHA-1 parcialmente rotos no se pueden calcular al revés (todavía), pero la ruptura en ellos mostró que tienen un efecto de avalancha ligeramente malo. Aunque creo que esa debilidad específica en su mayoría no afecta el caso de hash de contraseña + sal del que estamos hablando aquí. (Te ahorraré la explicación aquí por qué). Pero de todos modos, la regla general es: si se encuentra CUALQUIER debilidad en un primitivo criptográfico, comience a usar mejores cosas. Porque a menudo, cuando se descubre una debilidad, poco después se descubren otras más y peores.
- Descargo de responsabilidad: No soy un analista de criptomonedas, pero he estudiado seguridad informática desde 1987 y criptografía desde aproximadamente 1994.
- -- David Göthberg ( discusión ) 17:09, 19 de octubre de 2024 (UTC) [ respuesta ]
En realidad, parece que se puede mantener la contraseña mucho más segura si se descarta por completo la sal. Supongamos que la contraseña tiene 6 caracteres en minúsculas (308 915 776 combinaciones) y 10 bits de sal (1024 combinaciones). Descifrar la frase conociendo la contraseña y la sal lleva 0,001 s.
Eso significa que, aunque se conozca la sal, forzar la contraseña por la fuerza bruta tardará unos 3,5 días, algo perfectamente posible. Ahora bien, si no se tiene la sal, forzar las combinaciones 308.915.776*1024 = 316.329.754.624 tardará algo más de 10 años. Mientras tanto, los usuarios legítimos, para poder iniciar sesión con la contraseña, deben forzar los 1024 bits de sal, lo que hace que el inicio de sesión dure hasta 1 segundo, un tiempo todavía muy aceptable. —Comentario anterior sin firmar añadido por 213.180.137.171 (discusión) 15:15, 15 de noviembre de 2007 (UTC) [ responder ]
- En realidad, eso solo encarece el algoritmo, algo que se puede hacer de formas mucho mejores, como por ejemplo mediante múltiples iteraciones de hash. Sin embargo, siendo realistas, bloquear la máquina, al 100 % de la CPU, durante un segundo solo para verificar una contraseña podría no ser aceptable en muchos casos.
- Una sal conocida no está diseñada para dificultar la fuerza bruta de una contraseña única, sino para proteger contra la fuerza bruta masiva y las tablas precalculadas, lo que hace con bastante eficacia. 122.107.20.56 (discusión) 01:00, 3 de mayo de 2008 (UTC) [ responder ]
- Sí, lo es, creo que el autor original ha entendido mal cómo y por qué se usan las sales, el uso legítimo no necesita forzar nada, se supone que él debe conocer la sal, puede ser su nombre de usuario o algo almacenado en la misma base de datos, como dijo la persona anterior a mí, su propósito principal es detener las tablas arcoiris, no evitar la fuerza bruta, realmente no entendí tu razonamiento pero la sal no hace que sea más fácil forzar una contraseña -- RichoDemus ( discusión ) 10:55, 20 de mayo de 2008 (UTC) [ responder ]
- Según mi comprensión del salting, no es posible descartar por completo el salt, porque es necesario para autenticar al usuario. Creo que estoy de acuerdo con el usuario RichoDemus. -- AB ( discusión ) 00:45 21 feb 2009 (UTC) [ responder ]
¿Alguien conoce la etimología de la sal en este contexto? Rob.desbois 14:45, 5 de junio de 2006 (UTC) [ responder ]
- No, pero supongo que está relacionado con el concepto de poner sal en un sitio, como en el caso del fraude minero. Hace tiempo que me entró curiosidad y me parece recordar que el OED tiene una entrada de cierta antigüedad. ww 18:53, 5 de junio de 2006 (UTC) [ responder ]
- Supongo que la fuente más probable es que se trate de echar sal a la tierra . Los datos reales están "desfigurados" para que sea más difícil que un adversario los utilice. JRM · Discusión 12:17 1 jul 2006 (UTC) [ responder ]
- Ah, buenas sugerencias las vuestras. Así es como suelo pensar en ello: la sal es nuestro condimento más común
. Por eso tiendo a pensar en ella como la sal que "condimenta" la contraseña/clave. Por supuesto, entonces quizá debería llamarse "pimienta". Pero también, la sal es un potenciador del sabor bien conocido . Es decir, añadir un poco de sal a la comida hace que los demás sabores de la comida sean más fuertes. (No sé por qué funciona así, pero es un hecho bien conocido). Y la sal en criptografía hace que la contraseña/clave sea más fuerte. Así que creo que "sal" es una palabra excelente para ello en muchos sentidos. Y es una palabra corta, fácil de deletrear y pronunciar, fácil de traducir a todos los demás idiomas y no cambia el significado cultural cuando se traduce. ¡Es perfecta! -- David Göthberg 11:58, 25 de octubre de 2006 (UTC) [ responder ]- Hmmm... Sospecho que tenemos aquí una etimología popular que casi siempre es plausible (de lo contrario no se habría propuesto ni se habría difundido), pero que a menudo se equivoca. El primer punto que quisiera señalar es que, según mi percepción del idioma, la sal no es una especia. Las especias son exóticas (o lo fueron en algún momento), tienden a ser productos vegetales (corteza de árbol triturada, por ejemplo), se usan en cantidades bastante pequeñas y son completamente opcionales desde el punto de vista nutricional. La sal no cumple ninguna de esas condiciones, pero tal vez mi percepción de la "especia" difiere de la de otros hablantes de inglés. Después de todo, puedo quemar agua sin esforzarme. Me pregunto si existe una distinción similar en otros idiomas; parece que no existe tal distinción en sueco (la lengua materna de Davidgothberg, si entiendo bien).
- Mi suposición personal, completamente infundada, es que proviene de la frase "tómalo con pinzas". Tomfelker 23:22, 22 de octubre de 2007 (UTC) [ responder ]
- Pero me gusta la etimología/analogía, sea folklórica o no. ww 14:06, 25 de octubre de 2006 (UTC) [ responder ]
- Siempre he supuesto que el origen de "sal" es una especie de analogía inversa con el hecho de que se siembra un PRNG = generador de números pseudoaleatorios . El fragmento de galimatías que se introduce en el PRNG es una semilla porque es el comienzo de las cosas y lo que es determina todo lo que sucede después (la planta que crece en esa maceta depende de si la semilla es una semilla de geranio o de girasol). Por lo tanto, se intenta generar un poco de galimatías impredecible como una semilla . Sin embargo, cuando se genera un valor similar, pero si no se introduce en un PRNG, sino en un algoritmo hash, en realidad no se está utilizando como semilla para nada. Así, sal es una palabra que suena bastante similar (fonológicamente: cada una empieza con una 's', tiene un núcleo silábico de doble mora y termina en una consonante que difiere de la otra solo en la sonoridad, siendo por lo demás solo oclusivas alveolares) y tiene una especie de sentido de "idoneidad" que invita a etimologías populares como las que vemos aquí. Compárese con "especia" en "Cifrado Hasty Pudding: cifrado_y_descifrado " . -- Sburke ( discusión ) 12:11 17 mar 2013 (UTC) [ responder ]
- Dado que mi conocimiento del idioma inglés se ha ampliado desde mi antiguo comentario anterior: el usuario ww tiene razón en que estaba utilizando incorrectamente la palabra "especia" ya que soy sueco. La palabra sueca "krydda" se utiliza tanto en el sentido de " especia " como de " condimento ". Por eso actualicé mi comentario anterior.
- Pero desde entonces me enteré de que la expresión que JRM sugirió "salar la tierra" / "sembrar con sal" se usa figurativamente en inglés y otros idiomas. (Sólo conocía su trasfondo histórico como una forma de maldecir/destruir un área enemiga para evitar la agricultura futura). Así que ahora creo que esa es quizás la etimología más probable. (No debe confundirse con "sal de la tierra", que es algo positivo). Luego también están " bomba salada ", " salar la cola de un pájaro " y la sugerencia de ww " salar la mina ", pero encuentro que esos candidatos son menos probables. Pero todos encajan hasta cierto punto. Y como señaló Sburke, también suena bien. Así que sí, encaja en muchos sentidos.
- - David Göthberg ( discusión ) 06:04, 7 de mayo de 2024 (UTC) [ respuesta ]
- No estoy seguro de si este es el lugar para decirlo o no. Si no lo es, elimínenlo. Tengo una nota sobre el siguiente enlace "Almacenamiento de contraseñas: ¡bien hecho!" "Imagínense a un pirata informático que obtiene acceso al sistema a través de posibles errores del sistema operativo o del software del servidor y que puede leer la base de datos de usuarios".
- Si un pirata informático ha obtenido acceso a su base de datos, no importa si las contraseñas están cifradas o no, porque puede hacer todo el daño que necesite allí mismo. Por ejemplo: está en su tabla de inicio de sesión y usted tiene un hash md5 para una contraseña, inserta el suyo en su lugar y ¡zas! Ese usuario ya no tiene acceso, pero el pirata informático sí. Tenga esto en cuenta antes de tomar medidas drásticas para proteger datos que, en el momento en que usted ha sido pirateado, no son seguros, independientemente de los métodos de criptografía que haya utilizado.
He trasladado aquí la adición de 69.173.174.235, ya que no pertenece al artículo. Strad 17:47, 20 de junio de 2006 (UTC) [ responder ]
- Parece que estás difuminando la distinción entre el acceso de lectura y escritura a la base de datos del usuario, que obviamente son diferentes niveles de compromiso en muchos sistemas. 67.185.169.54 06:49, 3 de marzo de 2007 (UTC) [ responder ]
- Es cierto, pero esto queda fuera del alcance de esta página de discusión. --- JS ( T / C / WRE ) 16:00, 4 de mayo de 2007 (UTC) [ responder ]
¿Alguien sabe por qué el nombre del usuario no se usa simplemente como una sal por usuario? ¿Especialmente en los casos en los que la sal es semipública de todos modos? —Comentario anterior sin firmar agregado por 75.164.142.98 (discusión) 16:55, 16 de junio de 2008 (UTC) [ responder ]
- No sería un "grano" de sal particularmente valioso para nombres de usuario consistentes, como "root". -- MattiasAndersson ( discusión ) 15:18, 15 de agosto de 2008 (UTC) [ responder ]
- Se me ocurren dos razones en este momento:
- La sal también debe contener caracteres no alfanuméricos, lo cual el nombre de usuario no puede contener.
- Los nombres de usuario pueden tener longitudes muy variables, mientras que la sal probablemente debería tener al menos una longitud mínima. Sin embargo, esto se puede resolver utilizando un hash (de longitud estándar) del nombre de usuario como sal.
- -- AB ( discusión ) 01:59 21 feb 2009 (UTC) [ responder ]
- Una tercera razón es que si se utiliza el nombre de usuario como sal, el usuario nunca podrá cambiar su nombre de usuario (a menos que el sistema también lo obligue a cambiar manualmente su contraseña al mismo tiempo). De manera similar, había pensado en utilizar el número de fila de la base de datos como sal, pero eso evita que se copien usuarios en la base de datos (ya que el usuario copiado tendría un número de fila diferente, lo que haría que la contraseña fuera irrecuperable). -- GlenPeterson ( discusión ) 13:00, 29 de diciembre de 2010 (UTC) [ responder ]
- Además, tendría la misma sal en varios sitios, lo que permitiría a las personas ver si está usando la misma contraseña. Esto lo identificaría como un objetivo valioso. Tampoco hay ninguna razón para evitar problemas con la fuerza y los nombres Unicode inesperados y los cambios de nombre simplemente usando sal aleatoria, excepto unos pocos bytes guardados por usuario. Sin embargo, el nombre de usuario PUEDE usarse si desea convertir la contraseña en hash en el lado del cliente para aumentar la seguridad en tranzit. (Ya sea si no usa https o no confía en el sistema de CA o está preocupado por los certificados agregados por el usuario). Sin embargo, esta contraseña debe convertirse en hash OTRA VEZ en el lado del servidor con la sal adecuada.
- PD: Probablemente debería mencionar que no deberías usar sal aleatoria para el hash del lado del cliente, ya que requeriría que envíes la sal antes de iniciar sesión, lo que revelaría que el usuario está registrado. Enviar sal aleatoria para usuarios inexistentes no es una solución, ya que el atacante puede volver a verificar más tarde y ver si la sal cambió (es aleatoria). Xhunterx ( discusión ) 17:44, 2 de enero de 2017 (UTC) [ responder ]
Este artículo establece claramente que una sal para toda la base de datos de contraseñas es una forma de salado. Nunca había oído hablar de este uso del término antes. En mi humilde opinión, el hash de todas las contraseñas en combinación con una clave secreta es solo una forma de HMAC . Las fuentes de este artículo también parecen mencionar el salado en la forma que conozco: se genera una sal aleatoria para cada contraseña y se almacena con los mismos permisos de acceso que el hash. Las fuentes incluso dicen "junto con el hash". Para evitar discusiones como "en mi base de datos uso campos separados para sal y hash", lo amplié ligeramente. La línea de base es la misma: cada vez que necesitas verificar una contraseña, necesitas tanto la sal única como el hash único para esa contraseña.
¿Alguien puede proporcionar una buena fuente para la afirmación de que una clave secreta es una forma de salazón? Personalmente, no consideraría que la API de PHP , por nombrar algo, sea una buena fuente. Un escritor de API no tiene en mente una nomenclatura exacta, solo necesita decidir un nombre adecuado para una función y difícilmente investigaría los antecedentes sobre el significado exacto de la palabra.
<edit> He tachado la frase sobre el HMAC. En mi esfuerzo por ponerle nombre a la bestia, le puse un nombre equivocado. Pensé en algo como "probarle al sistema de autenticación que él (el sistema de autenticación) escribió la entrada hash". Obviamente, esa es una discusión completamente diferente en lo que respecta al acceso de escritura a la base de datos. Lo siento. No sé un nombre adecuado para eso. </edit> 130.89.163.83 (discusión) 17:36, 20 de junio de 2009 (UTC) [ responder ]
- Tienes razón, y en verdad la mayoría de los expertos creen que es mejor tener una sal no estática para las contraseñas, de lo contrario te expones a tablas arco iris.
- De hecho... a menos que alguien comente lo contrario en los próximos días, voy a agregar una sección para hablar sobre las mejores prácticas con el uso de la sal. —Comentario anterior sin firmar agregado por ElectroKitty (discusión • contribuciones ) 15:44, 1 abril 2010 (UTC)[ responder ]
- Este artículo es, de hecho, muy confuso cuando dice "Para una mejor seguridad, el valor de la sal se mantiene en secreto. Para determinar una contraseña a partir de un hash robado, un atacante no puede simplemente probar contraseñas comunes...", lo que implica que (1) solo hay un valor de sal y (2) se mantiene separado de los hashes y es "más" secreto que ellos. Esto es incoherente con el uso típico y requerido de las sales con hashes de contraseñas, donde las sales son por hash y se mantienen tan secretas como los hashes (y viceversa), no "más" secretas (si esto fuera posible, los hashes se mantendrían preferiblemente igual de secretos también, por lo que no es "más"). Sin embargo, a veces tiene sentido introducir lo que se ha llamado un "parámetro local" (al menos en algunas discusiones sobre el hash de contraseñas que ocurrieron en la década de 1990, por ejemplo, [1]): un segundo valor similar a una sal que se usa junto con (¡no en lugar de!) las sales por hash normales. De hecho, este parámetro local se puede almacenar por separado de la base de datos de hash+sal de contraseñas (no exactamente "más secreto", solo separado hasta cierto punto), y podría proporcionar seguridad adicional en algunos casos especiales (por ejemplo, volcado de copia de seguridad filtrado para la base de datos, pero no para el archivo de configuración del programa). Desafortunadamente, también tiene desventajas (es más difícil mover/fusionar entradas de usuario entre diferentes instancias/instalaciones del sistema/programa). Creo que el artículo necesita ser revisado para evitar esta confusión. Mi sugerencia es que se elimine el párrafo que comienza con "Para mayor seguridad, el valor de sal se mantiene en secreto...". En su lugar, se puede agregar un párrafo que explique que "con el hash de contraseñas, las sales por hash no necesitan mantenerse más secretas que los hashes, sin embargo, a veces se puede agregar un parámetro local y mantenerlo separado" más adelante en el artículo. Por supuesto, tendría que ser más detallado, como este comentario que escribí, así que tal vez esto merezca una sección separada. También está bien omitir por completo el término "parámetro local" (por lo que simplemente eliminar el párrafo confuso es un buen comienzo), pero entonces es probable que el problema o la confusión sigan surgiendo. Solardiz (discusión) 21:05 12 ene 2011 (UTC) [ responder ]
- Correcto. Eliminé ese texto confuso junto con un montón de otras nociones extrañas. ★NealMcB★ ( discusión ) 05:02 16 feb 2011 (UTC) [ responder ]
- Bueno, algunas fuentes probablemente sean confusas ya que los escritores conocen la historia de las sales:
- En los viejos tiempos (principios de los años 90) solía haber una sola sal para todo el archivo de contraseñas. Eso protegía contra un atacante que usara la misma tabla arco iris contra varias organizaciones diferentes y protegía las contraseñas si un usuario reutilizaba su nombre de usuario y contraseña en otra organización. En aquel entonces, la mayoría de los sistemas tenían solo unos pocos cientos de usuarios, o como máximo unos pocos miles de usuarios.
- Pero luego la gente pasó a utilizar la opción más segura de utilizar una sal única para cada usuario en el archivo de contraseñas.
- Pero la sal de usuario a menudo se combina con una sal secreta más exclusiva para ese sistema. En uno de los principales sistemas aquí en mi ciudad, no almacenaban esa sal única en ningún disco, sino que los administradores principales tenían que introducirla manualmente cada vez que se reiniciaba el servidor de contraseñas (quizás una vez al año en promedio) directamente en el teclado del servidor de contraseñas. La sal se almacenaba en un papel doblado en su caja fuerte física, de la que solo los tres administradores principales tenían la llave y el código, y esa caja fuerte estaba en su oficina, que estaba vigilada las 24 horas del día, los 7 días de la semana, los 365 días del año. La razón de la vigilancia las 24 horas del día, los 7 días de la semana, es principalmente porque la ciudad necesita servicios las 24 horas del día, los 7 días de la semana. Y la razón de la vigilancia las 24 horas del día, los 7 días de la semana, es principalmente porque hay tanto equipo costoso allí, y tuvieron robos recurrentes de las computadoras en los edificios adyacentes hasta que pusieron alarmas en todo y aumentaron la vigilancia. (Yo trabajaba en uno de los edificios adyacentes, y algunos de los administradores habituales de la oficina de la ciudad eran miembros del club de informática de nuestra ciudad, así que solíamos juntarnos en las noches de club y jugar a Star Craft y hablar de seguridad informática). Sé que el tiempo habitual que tarda la policía en llegar a ese lugar si se activa la alarma antirrobo suele ser de tres minutos como máximo. Está en la misma zona que nuestro museo de arte, todos los ladrones que han intentado robar un cuadro allí han sido atrapados por la policía antes de que pudieran llegar a la puerta de salida. Así que, casi por accidente, esa sal extra se almacenó de una forma ridículamente segura.
- -- David Göthberg ( discusión ) 13:25, 19 de octubre de 2024 (UTC) [ respuesta ]
El artículo cuenta actualmente con tres enlaces externos. De ellos, uno ("Morris, Robert; Thompson, Ken (1978-04-03). Password Security: A Case History") es excelente: tiene valor histórico y sigue siendo relevante. Los dos restantes ("Wille, Christoph (2004-01-05). "Almacenamiento de contraseñas - ¡bien hecho!" y "Primer on Unix password structure") son cuestionables: no mencionan el fortalecimiento de claves - su importancia (¡es absolutamente necesario para que el hasheo de contraseñas esté "bien hecho"!) y su uso por los hashes de contraseñas Unix (el "Primer" específico menciona "MD5", pero no menciona que el algoritmo real es de nivel superior y se basa en 1000 iteraciones de MD5). Sería deseable tener mejores "enlaces externos" para estos temas, o al menos se deben mencionar los inconvenientes de estos dos junto a los enlaces - como en: "(no menciona la necesidad de fortalecer la clave )" (y "uso de" en el otro enlace). -- Solardiz (discusión) 21:23, 12 de enero de 2011 (UTC) [ responder ]
Permítanme sugerir los siguientes enlaces/referencias: la colección de publicaciones de Terry Ritter en sci.crypt de una discusión sobre las sales, Handbook of Applied Cryptography de Menezes et al., Capítulo 10, página 390 (o página 7 en el archivo PDF del Capítulo 10 (descargable de forma libre y legal, gracias a los autores y al editor), y finalmente mi propio artículo sobre el hash de contraseñas adecuado en PHP (por supuesto, puede que sea parcial, pero creo que explico la esencia de la salazón y el estiramiento/fortalecimiento correctamente, pero sin demasiadas palabras). -- Solardiz (discusión) 21:38, 12 de enero de 2011 (UTC) [ responder ]
Actualización : me gustaría recomendar el artículo Secure Salted Password Hashing - Do it Right como referencia externa. Es bastante completo y está bien escrito. --Mhack (discusión) 13:55, 19 de abril de 2013 (UTC) [ responder ]
Corrígeme si me equivoco, pero Salt no hace que el ataque de fuerza bruta sea más lento, ya que analizaría todos los valores posibles sin tener en cuenta ninguna suposición, a diferencia de lo que hace el ataque de diccionario (el ataque de diccionario supone que el usuario no utilizará algunos patrones de texto). Mike2learn ( discusión ) 11:49, 10 de mayo de 2011 (UTC) [ responder ]
- El uso de una sal puede hacer que el descifrado por fuerza bruta sea más lento Para descifrar la contraseña dada la sal y el hash, debe concatenar la sal con su contraseña candidata y luego hacer un hash del resultado concatenado. Hacer un hash del resultado concatenado llevará más tiempo que hacer un hash de la contraseña candidata, que es lo que se haría si no hubiera sal. Supongamos, por ejemplo, que con nuestro algoritmo hash, si toma n segundos hacer un hash de un mensaje de tamaño m, entonces toma 2*n segundos hacer un hash de un mensaje de tamaño 2*m (tiempo lineal en la longitud del mensaje). Considere usar una sal que sea mucho más grande que el tamaño típico de la contraseña, por ejemplo, 1000 veces más grande. Entonces, la fuerza bruta tomará aproximadamente 1000 veces más de lo que tomaría sin sal. La autenticación también tomaría 1000 veces más, pero para un solo inicio de sesión esto puede ser completamente aceptable (también tenga en cuenta que no tiene que ser 1000). -- Thedatamatrix (discusión) 00:46 4 ago 2013 (UTC) [ responder ]
- Esa afirmación sobre el craqueo más lento contiene la restricción "(pero no en el caso de craquear una sola contraseña)" y el párrafo continúa explicando por qué. El punto es que sin sal, puedes atacar todos los hashes al mismo tiempo, sin un aumento en el tiempo de ejecución. Con sal, esto no es posible y solo puedes atacar simultáneamente contraseñas que tengan la misma sal (que es también la razón por la que creo que la recomendación de elegir sales aleatoriamente es una tontería: la elección aleatoria aumenta innecesariamente la posibilidad de colisiones, es decir, 2 o más sales idénticas). Incluso con sal (a menos que sea de gran tamaño, como sugirió Thedatamatrix), un ataque a una sola contraseña en particular no se ralentiza, solo pierdes la capacidad de craquear múltiples contraseñas simultáneamente. Si no está claro cómo funcionarían los ataques simultáneos contra hashes sin sal, aquí hay una explicación: lee todos los hashes que quieras craquear en la RAM (no es un problema para los escenarios de ataque típicos, de lo contrario, simplemente compra más RAM), insertándolos en una estructura de datos con búsqueda rápida (tabla hash, árbol equilibrado, etc.). La estructura de datos solo necesita poder responder a la pregunta "¿contiene el hash X?", idealmente en tiempo O(1). Luego, comience a descifrar mediante el hash de la primera contraseña de su espacio de búsqueda de contraseñas, busque el hash en su estructura de datos, guarde la contraseña en caso de que se produzca un resultado, de lo contrario, repita con la próxima contraseña. Encontrará todas las contraseñas contenidas en su espacio de búsqueda, sin importar cuántos hashes haya cargado en su estructura de datos. Muchas estructuras de datos no tienen un tiempo de acceso O(1), pero O(log(n)) sigue siendo lo suficientemente rápido y lo logran la mayoría de las estructuras de datos optimizadas para un acceso rápido (con O(log(n)), su tiempo de ejecución aumenta con una mayor cantidad de hashes, pero solo levemente porque el tiempo de ejecución aún está dominado por el cálculo de hashes, particularmente si se usan múltiples rondas, lo que hace con cualquier esquema de hashes de contraseñas decente como PBKDF2). Con las sales, crea de manera efectiva muchos espacios de contraseñas distintos, lo que evita este tipo de ataque. Catskineater (discusión) 14:43 21 oct 2015 (UTC) [ responder ]
Todo este artículo necesita ayuda, y aquí hay un ejemplo: para UNIX, la contraseña real se movió a un archivo que sólo las cuentas privilegiadas podían leer, como /etc/shadow en Solaris y /etc/security/passwd en AIX. No estoy seguro de cuándo comenzó esto, pero sé que Solaris 2.6 lo hacía y creo que Solaris 2.5 también. ¡Y Solaris 2.6 salió hace más de una década! ¡¡Es mucha historia para pasarla por alto!! Argel1200 ( discusión ) 18:58, 11 de mayo de 2011 (UTC) [ responder ]
Me gustan los ejemplos de funciones de la página de la tabla Rainbow . Esta página debería tener ejemplos tan explícitos. IOLJeff ( discusión ) 18:18, 13 de septiembre de 2011 (UTC) [ responder ]
Secundado... -- Molivier ( discusión ) 22:02 7 jun 2012 (UTC) [ responder ]
Alguien que sea bueno haciendo archivos .png rápidamente debería considerar hacer una ilustración para esta página. Podría ayudar a visualizar cómo y cuándo se agregan sales a las contraseñas, y el efecto que tienen en los hashes. Este parece ser uno de esos conceptos en los que una imagen puede decir mil palabras. — Comentario anterior sin firmar agregado por Exercisephys ( discusión • contribuciones ) 22:59, 22 de mayo de 2012 (UTC) [ responder ]
No entiendo de criptografía, por lo que no soy la persona indicada para editarlo, pero la primera oración no tiene sentido y no es gramaticalmente correcta. Es muy confuso. Byates5637 ( discusión ) 21:24 23 may 2012 (UTC) [ responder ]
- Estoy de acuerdo, pero por un motivo diferente. La primera oración actual dice: "En criptografía, una sal es un dato aleatorio..."
- Sin embargo, la fuente citada afirma: "Sal: un valor no secreto utilizado en un proceso criptográfico".
- La fuente no indica que la sal deba ser aleatoria, solo que debe ser "no secreta". 24.243.2.150 (discusión) 00:52 8 ago 2024 (UTC) [ responder ]
- Revisé la primera oración del artículo cuando Byates5637 lo leyó. Creo que era gramaticalmente correcta en ese entonces. Y la versión actual dice "una sal son datos aleatorios que se alimentan como entrada adicional a a", lo que creo que también es una gramática correcta, aunque personalmente eliminaría el "an" y simplemente diría "una sal son datos aleatorios que se alimentan como entrada adicional a a" . Creo que depende de si ves esos datos como una sola cosa o como un montón de datos (o bits). Pero no soy un hablante nativo de inglés.
- Y respecto a las propiedades de una sal:
- La sal no tiene por qué ser "no secreta", solo que normalmente está bien si es pública, por ejemplo, almacenada en un archivo de contraseñas al que algunos o muchos usuarios tienen acceso. Sin embargo, si puede hacer que su sal sea secreta, es aún mejor, eso convierte la sal en una segunda clave y hace que las cosas sean más seguras. Por eso, hoy en día, la mayoría de los sistemas no permiten que los usuarios vean el archivo de contraseñas.
- En segundo lugar: una sal no tiene por qué ser un dato aleatorio, sino que:
- La sal tiene que ser suficientemente única (para que no usemos la misma sal varias veces). Usar la fecha y hora actuales (incluido el segundo actual) puede parecer suficientemente único al principio. Pero los relojes fallan y las computadoras pueden ser engañadas para que piensen que es otra hora y fecha, incluso si usan tiempo GPS (solo coloque un transmisor GPS falso al otro lado de la calle con una señal más fuerte que los satélites y podrá retroceder en el tiempo). Si ve un sistema de cifrado que depende de "tiempo seguro", puede estar bastante seguro de que el diseñador era un aficionado. Tenemos mejores soluciones que usar el tiempo para prácticamente todos los casos de uso.
- Es bueno que la sal sea impredecible para que un atacante no pueda adivinarla antes de que la creemos y la usemos, y así no pueda comenzar a hacer cálculos con anticipación.
- Simplemente usar un contador e incrementar el valor de la sal con uno por cada uso dentro de una sesión está bien, siempre y cuando comiences el contador con un valor aleatorio impredecible grande, de modo que la próxima sesión no use los mismos valores. Pero usar un contador que se ejecute durante varias sesiones es un gran no-no, ya que si guardas tu valor actual en el disco para saber dónde continuar el conteo, y ese guardado falla por alguna razón, entonces en la próxima sesión leerás el valor anterior del disco y comenzarás desde el mismo valor que en tu sesión anterior. Lo mismo sucederá si restauraste tu sistema desde una copia de seguridad. Pero usar un contador es un poco tonto ya que ahora tenemos generadores de números pseudoaleatorios criptográficamente seguros tan buenos y rápidos que podemos usar dentro de una sesión (pero, por supuesto, debe iniciarse desde un número aleatorio verdadero).
- La forma más sencilla y segura de cumplir todos los criterios anteriores es utilizar un valor aleatorio grande (digamos al menos 100 bits), por lo que las colisiones (reutilización del mismo valor) se vuelven muy poco probables.
- Espero no haber confundido ninguno de los criterios con IV ( vector de inicialización ) y nonce , ya que son muy similares. Tengo tendencia a mezclarlos.
- -- David Göthberg ( discusión ) 11:25, 19 de octubre de 2024 (UTC) [ respuesta ]
En la sección "Beneficios", dice: "Las contraseñas sin sal elegidas por humanos tienden a ser vulnerables a ataques de diccionario ya que tienen que ser cortas y lo suficientemente significativas para ser memorizadas". Las contraseñas con sal NO son menos vulnerables a un ataque de diccionario a menos que la sal esté oculta. Si conoce la sal y el hash, un ataque de diccionario terminará exactamente en la misma cantidad de iteraciones que si no hubiera sal. Lo único que llevaría más tiempo es tener que hacer un hash de una cadena más grande cada vez (la contraseña candidata + la sal, en lugar de solo la contraseña candidata). Si no conoce la sal, es posible que no pueda descifrar la contraseña de manera efectiva, aunque podría encontrar la cadena concatenada. Puede ser fácil separar la contraseña de la sal si el final de la cadena concatenada se ve drásticamente diferente del frente (uso "frente" y "fin" asumiendo que el salado consiste en una concatenación simple). Haré un cambio para señalar esto si no hay objeciones. -- Thedatamatrix (discusión) 00:56 4 ago 2013 (UTC) [ responder ]
- No. Si no se utilizan sales, o si se utiliza una única sal para todo el archivo de contraseñas, el atacante convierte cada palabra en un hash del diccionario y luego comprueba si alguna de las cuentas tiene ese hash. Por lo tanto, sin sales únicas, puede atacar todas las cuentas del mismo sistema a la vez (si tiene el archivo de contraseñas que contiene los nombres de las cuentas y las contraseñas en hash, y conoce la sal única, si la hay). Con una sal diferente para cada cuenta, el atacante tiene que realizar un ataque de diccionario completo contra cada cuenta, una a la vez, para encontrar las cuentas que utilizan contraseñas cortas que existen en el diccionario.
- - David Göthberg ( discusión ) 13:51, 19 de octubre de 2024 (UTC) [ respuesta ]
¿No debería ser sal estática en lugar de sal pública? A menos que me esté perdiendo algo, la sección habla de sal estática. Errores comunes -> Sal pública o reutilización de sal Xhunterx ( discusión ) 17:54, 2 de enero de 2017 (UTC) [ responder ]
Está claro que no tendría sentido que se generara una sal cada vez que se introduce una contraseña en un sistema. Si fuera así, el hash de la concatenación de la nueva sal y la contraseña del usuario no coincidiría con el hash almacenado en el sistema. Sin embargo, esto no se indica explícitamente en el artículo y al principio me confundí. Propongo que alguien con más conocimientos cambie el tercer párrafo de la primera sección de:
Se genera aleatoriamente una nueva sal para cada contraseña. En una configuración típica, la sal y la contraseña (o su versión después de la ampliación de la clave) se concatenan y se procesan con una función hash criptográfica, y el resultado (pero no la contraseña original) se almacena con la sal en una base de datos. El hash permite una autenticación posterior sin conservar y, por lo tanto, arriesgar la contraseña de texto simple en caso de que se vea comprometido el almacén de datos de autenticación.
a:
Se genera aleatoriamente una nueva sal para cada contraseña y luego el sistema la almacena . En una configuración típica, la sal y la contraseña (o su versión después de la ampliación de la clave) se concatenan y se procesan con una función hash criptográfica, y el resultado (pero no la contraseña original) se almacena con la sal en una base de datos. Durante cada intento de inicio de sesión, la concatenación de la sal y la contraseña adivinada se codifican y se comparan con el hash guardado. El hash permite una autenticación posterior sin conservar y, por lo tanto, arriesgar la contraseña de texto simple en caso de que se vea comprometido el almacén de datos de autenticación.
Bhbuehler ( discusión ) 05:33 15 jul 2017 (UTC) [ responder ]
- Bhbuehler|Bhbuehler, bien por ti, y te lo agradezco. Venía aquí para publicar exactamente el mismo comentario y gracias a Dios vi que ya lo habías publicado. Simplemente no es posible que la sal no se almacene. (Por supuesto, la sal se puede almacenar como codificada). Y eso lleva a la pregunta "¿De qué sirve?" Porque cualquiera que pueda robar la lista de nombres de usuario y contraseñas con sal/codificadas, y pueda robar el algoritmo que el sitio usa para codificar, también puede robar las sales de una forma u otra. 204.155.230.3 ( discusión ) 22:25, 29 de marzo de 2020 (UTC)Christopher L. Simpson [ responder ]
- Nada de esto ayuda al atacante. Si el sistema A crea un hash de una contraseña y el sistema B crea un hash de la misma contraseña, cualquiera que robe los hashes puede saber que se utilizó la misma contraseña. Si el sistema A crea un hash de una contraseña con Salt A y el sistema B crea un hash de la misma contraseña con Salt B, incluso si los salts se publican, alguien que robe los hashes no puede saber que se utilizó la misma contraseña.
- Como dice [2]:
- "Las tablas de búsqueda y las tablas arco iris solo funcionan porque cada contraseña se codifica de la misma manera. Si dos usuarios tienen la misma contraseña, tendrán los mismos hashes de contraseña. Podemos prevenir estos ataques al aleatorizar cada hash, de modo que cuando se codifica la misma contraseña dos veces, los hashes no sean los mismos.
- Podemos aleatorizar los hashes agregando o anteponiendo una cadena aleatoria, llamada sal, a la contraseña antes de aplicar el hash. Como se muestra en el ejemplo anterior, esto convierte el mismo hash de contraseña en una cadena completamente diferente cada vez. Para verificar si una contraseña es correcta, necesitamos la sal, por lo que generalmente se almacena en la base de datos de la cuenta de usuario junto con el hash, o como parte de la cadena hash en sí.
- La sal no necesita ser secreta. Con solo aleatorizar los hashes, las tablas de búsqueda, las tablas de búsqueda inversa y las tablas arco iris se vuelven ineficaces. Un atacante no sabrá de antemano cuál será la sal, por lo que no puede calcular previamente una tabla de búsqueda o una tabla arco iris. Si la contraseña de cada usuario se codifica con una sal diferente, el ataque de la tabla de búsqueda inversa tampoco funcionará.
- Véase también: Explicar el hash y la salazón como si tuviera cinco años --04:46, 30 de marzo de 2020 (UTC)
Un pequeño detalle: .NET no es un lenguaje. Es un framework, si se quiere, que admite varios lenguajes. — Comentario anterior sin firmar añadido por 184.71.25.218 (discusión) 12:50, 2 julio 2019 (UTC) [ responder ]
