Actualmente estamos almacenando contraseñas de texto sin formato para una aplicación web que tenemos.Reemplazar la contraseña de texto sin formato para la aplicación
Sigo abogando por pasar a un hash de contraseñas, pero otro desarrollador dijo que esto sería menos seguro: más contraseñas podrían coincidir con el hash y un ataque de diccionario/hash sería más rápido.
¿Hay algo de cierto en este argumento?
Absolutamente ninguno. Pero no importa. He publicado una respuesta similar antes:
Es desafortunado, pero las personas, incluso los programadores, son demasiado emocionales para ser fácilmente influidos por la discusión. Una vez que ha invertido en su puesto (y, si publicas aquí, lo está haciendo), no es probable que lo convenzas solo con los hechos. Lo que debes hacer es cambiar la carga de la prueba. Debes sacarlo en busca de datos que él espera que te convenzan y, al hacerlo, aprender la verdad. Desafortunadamente, él tiene el beneficio del status quo, por lo que tienes un camino difícil allí.
No soy un experto en seguridad pero tengo la sensación de que si el texto plano fuera más seguro, no existiría el hashing en primer lugar.
-1: Hashing se utiliza para mucho más que las contraseñas. Y solo porque algo existe no significa que tenga algún valor (aunque en este caso sí lo es). Una explicación real tendría un valor agregado. –
No hay excusas para guardar contraseñas de texto sin formato en la aplicación web. Utilice un algoritmo hash estándar (SHA-1, no MD5!) Con un valor de sal, de modo que los ataques de arco iris sean imposibles.
md5 es completamente inapropiado para contraseñas hash –
He actualizado la respuesta, gracias @ joel-coehoorn. – qbeuek
Si no lo hace la sal su contraseña, usted es sospechoso de los ataques de mesa arco iris (Diccionarios precompilados que tienen entradas válidas para un hash dado)
El otro desarrollador debe dejar de hablar de seguridad si estás almacenar contraseñas en texto plano y comienza a leer sobre seguridad.
Las colisiones son posibles, pero no son un gran problema para las aplicaciones de contraseñas (generalmente son un problema en áreas donde los hash se usan para verificar la integridad de los archivos).
Así que sal de sus contraseñas (agregando el Salt al lado derecho de la contraseña *) y use un buen algoritmo hash como SHA-1 o preferiblemente SHA-256 o SHA-512.
PD: Un poco más de detalles sobre Hashes here.
* no estoy seguro de si la sal debe o no al principio o al final de la cadena. El problema es que si tiene una colisión (dos entradas con el mismo hash), agregar Sal al lado "incorrecto" no cambiará el hash resultante. De ninguna manera, no tendrá grandes problemas con Rainbow Tables, solo con colisiones
No entiendo cómo las demás contraseñas de los demás desarrolladores pueden coincidir con el hash '.
Existe el argumento de que un "ataque de hash sería más rápido", pero solo si no se saltean las contraseñas ya que son hash. Normalmente, las funciones hash le permiten proporcionar una sal que hace que el uso de la tabla hash conocida sea una pérdida de tiempo.
Personalmente, yo diría 'no'. Basado en lo anterior, así como en el hecho de que si de alguna manera obtiene una exposición de texto claro, un valor de hashed salado es de poco valor para alguien que intenta ingresar. Hashing también proporciona el beneficio de hacer que todas las contraseñas 'se vean' mismo largo.
es decir, si hash cualquier cadena siempre da como resultado un hash de 20 caracteres, entonces si solo tiene el hash para mirar, no puede decir si la contraseña original era de ocho caracteres o dieciséis, por ejemplo.
En teoría, sí. Las contraseñas pueden ser más largas (más información) que un hash, por lo que existe la posibilidad de colisiones hash. Sin embargo, la mayoría de los ataques se basan en diccionarios, y la probabilidad de colisiones es infinitamente más pequeña que una coincidencia directa exitosa.
más contraseñas podrían coincidir con el hash y un ataque de diccionario/hash sería más rápido.
Sí y no. Use un algoritmo hash moderno, como una variante SHA, y ese argumento se obtiene muy, muy semana. ¿De verdad necesitas estar preocupado si ese ataque de fuerza bruta va a tomar solo 352 años en vez de 467 años? (Una broma anecdótica allí). El valor que se obtendrá (no tener la contraseña almacenada en texto sin formato en el sistema) supera con creces la preocupación de su colega.
De Wikipedia
Algunos almacén de usuarios de sistemas informáticos contraseñas, con el que comparar registro de usuario en intentos, como texto plano. Si un atacante obtiene acceso a un almacén interno de contraseñas , todas las contraseñas y todas las cuentas de usuario serán comprometidas. Si algunos usuarios emplean la misma contraseña para cuentas en sistemas diferentes, esos también serán comprometidos.
sistemas más seguros almacenan cada contraseña en un forma protegida mediante cifrado, por lo que el acceso a la contraseña real seguirá siendo difícil para un fisgón que gana acceso interno al sistema, mientras que validación de acceso de los usuarios intentos sigue siendo posible
Un acceso común almacena solo una forma "hash" de de la contraseña de texto sin formato . Cuando un usuario escribe una contraseña en un sistema de este tipo, el software de manejo contraseña corre a través de una criptográfica algoritmo de hash , y si el valor hash generado a partir de la entrada del usuario coincide con el hash almacenado en la base de datos contraseña, el el usuario tiene acceso permitido. El valor hash es creado al aplicar una función hash criptográfica a una cadena que consiste en de la contraseña enviada y, generalmente, otro valor conocido como sal . La sal previene que los atacantes construyan una lista de valores hash para contraseñas comunes. MD5 y SHA1 son funciones hash criptográficas frecuentemente utilizadas .
Hay mucho más que puede leer sobre el tema en esa página. En mi opinión, y en todo lo que he leído y trabajado, el hash es un mejor escenario a menos que uses un algoritmo muy pequeño (< de 256 bits).
Es cierto que si has algo, sí, habrá colisiones por lo que sería posible que dos contraseñas diferentes desbloqueen la misma cuenta.
Sin embargo, desde un punto de vista práctico, ese es un argumento pobre: una buena función de hash (md5 o sha1 estaría bien) puede garantizar que para todas las cadenas significativas, especialmente cortas, no habrá colisiones. Incluso si lo hubiera, tener dos contraseñas para una cuenta no es un gran problema: si alguien está en posición de adivinar las contraseñas de forma aleatoria lo suficientemente rápido como para poder ingresar, usted tiene problemas mayores.
Me atrevería a decir que el almacenamiento de las contraseñas en texto plano representa un riesgo de seguridad mucho mayor que las colisiones hash en la coincidencia de contraseñas.
MD5 es _nunca_ está bien. – SLaks
@SLaks: md5, roto como está, es aún mejor que almacenar contraseñas de texto sin formato. –
Depende de lo que defiende. Si se trata de un atacante que tira de su base de datos (o engaña a su aplicación para que muestre la base de datos), entonces las contraseñas de texto plano son inútiles. Hay muchos ataques que se basan en convencer a la aplicación de que libere sus datos privados: inyección de SQL, secuestro de sesión, etc. A menudo es mejor no mantener la información en absoluto, sino mantener la versión hash tan mal que los chicos no pueden usarla fácilmente. .
Como sugiere su compañero de trabajo, esto puede ser trivialmente derrotado ejecutando el mismo algoritmo hash contra un diccionario y usando tablas de arcoíris para extraer la información. La solución habitual es utilizar una sal secreto más la información de usuario adicional para que los resultados hash único- algo como:
String hashedPass=CryptUtils.MD5("alsdl;ksahglhkjfsdkjhkjhkfsdlsdf" + user.getCreateDate().toString() + user.getPassword);
Mientras su sal es secreto, así como su atacante no conoce la fecha exacta de la creación el registro del usuario, un ataque de diccionario fallará, incluso en el caso de que puedan desplegar el campo de contraseña.
¿Qué? Si el atacante tiene su tabla de "usuarios", tendrá la Fecha de creación del usuario. Si CreationDate no está en la tabla de "usuarios", ¿cómo iniciará la aplicación el inicio de sesión? Salar con datos únicos para cada usuario es una buena idea, pero también es un hecho que el atacante tendrá acceso a ella. El objetivo de esto es que el atacante tendría que crear tablas de arco iris separadas para cada usuario. Y aquí es donde entran los algos de hash lentos. – Shinhan
La sal no tiene que ser secreta, y no debería ser igual para todos los usuarios. Entonces, se puede generar una tabla de arcoíris con esa sal. En cambio, cada usuario debe tener una sal generada al azar. No necesita ser tan secreto. Puedes publicarlo si quisieras. El punto es que un ataque completo de arco iris solo sería efectivo contra un máximo de un usuario a la vez. – ZaBlanc
S/often/always /. Y md5 para el código de ejemplo? Para vergüenza –
Encontré este mismo problema exactamente en mi lugar de trabajo. Lo que hice para convencerlo de que el hashing era más seguro fue escribir una inyección SQL que devolvió la lista de usuarios y contraseñas de la sección pública de nuestro sitio. Se intensificó de inmediato como un problema de seguridad importante :)
Para prevenir contra el diccionario/ataques de hash estar seguro para discutir en contra de una ficha que es única para cada usuario y estático (nombre de usuario/Fecha de ingreso/userguid funciona bien)
Nada es menos seguro que almacenar contraseñas de texto sin formato. Si está utilizando un algoritmo de hashing decente (al menos SHA-256, pero incluso SHA-1 es mejor que nada), entonces sí, las colisiones son posibles, pero no importa porque dado un hash, es imposible * calcular qué cadenas de hash a él. Si hash el nombre de usuario CON la contraseña, entonces esa posibilidad también se va por la ventana.
* - técnicamente no es imposible, pero "computacionalmente imposible"
Si el nombre de usuario es "Graeme" y la contraseña es "stackoverflow", a continuación, crear una cadena "Graeme-stackoverflow-1234", donde 1234 es un azar número, luego hash y almacenar "hashoutput 1234" en la base de datos. Cuando se trata de validar una contraseña, tome el nombre de usuario, la contraseña suministrada y el número desde el final del valor almacenado (el hash tiene una longitud fija para que siempre pueda hacer esto) y cópielos juntos, y compárelos con el hash parte del valor almacenado.
Hay un viejo dicho acerca de los programadores que pretenden ser criptógrafos :)
Jeff Atwood tiene un buen post sobre el tema: You're Probably Storing Passwords Incorrectly
Para responder más ampliamente, estoy de acuerdo con todo lo anterior, la hash lo hace más fácil en teoría para obtener la contraseña del usuario ya que varias contraseñas coinciden con el mismo hash. Sin embargo, es mucho menos probable que alguien obtenga acceso a su base de datos.
Espero que me perdones para tapar una solución que escribí sobre esto, el uso de JavaScript del lado cliente para cifrar la contraseña antes de que sea transmitido: http://blog.asgeirnilsen.com/2005/11/password-authentication-without.html
buena captura allí - realmente es una respuesta emocional del compañero de trabajo del OP. Dirigirse a los Fuzzies cálidos probablemente sea más productivo que la lógica y las métricas difíciles. ¿Tal vez presionar la opción de algoritmo de hash en el colega para que tengan más información sobre la solución adecuada? –
Tiene un muy buen punto aquí. No mencioné en la pregunta, pero este era su código, él lo implicó de esta manera. Ahora es mi código, así que podría cambiarlo unilateralmente, pero preferiría permitirle que me guarde la cara/estoy de acuerdo en caso de que necesite más ayuda para entender el código ... –