Es MD5 menos seguro que el SHA et.al.en un sentido práctico?
https://stackoverflow.com/questions/770900
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
He visto un pocos preguntas y respuestas en ENTONCES, lo que sugiere que el MD5 es menos seguro que algo como el SHA.
Mi pregunta es, Es esta vale la pena preocuparse en mi situación?
He aquí un ejemplo de cómo lo estoy usando:
- En el lado del cliente, me estoy dando un "seguro" de la suma de comprobación de un mensaje mediante la anexión de la hora actual y una contraseña y, a continuación, hash usando MD5.Así:
MD5(message+time+password). - En el lado del servidor, estoy revisando este hash contra el mensaje que se envía usando mi conocimiento de la hora en que fue enviado y la contraseña del cliente.
En este ejemplo, realmente estoy mejor uso de SHA en lugar de MD5?
En qué circunstancias sería la elección de la función de hash realmente la materia en un sentido práctico?
Editar:
Solo para aclarar - en mi ejemplo, hay algún beneficio de mudarse a un algoritmo SHA?
En otras palabras, es posible que en este ejemplo que alguien envíe un mensaje correcto y un hash sin saber la contraseña compartida?
Más Ediciones:
Disculpas por repitió en la edición de yo no fui claro con lo que me estaba pidiendo.
Solución
Sí, es vale la pena preocuparse en la práctica.MD5 es tan quebrantado que los investigadores han sido capaces de forjar certificados falsos que correspondía al real certificado firmado por una autoridad de certificación.Esto significaba que eran capaces de crear sus propias falso certificado de la autoridad, y por lo tanto podría suplantar a cualquier banco o a la empresa que se sentía como con los navegadores totalmente de confiar en ellos.
Ahora, esto les llevó a una gran cantidad de tiempo y esfuerzo utilizando un cluster de PlayStation 3, y varias semanas para encontrar una adecuada colisión.Pero una vez roto, un algoritmo de hash que es peor, nunca mejor dicho.Si usted se preocupa en absoluto acerca de la seguridad, sería mejor elegir una ininterrumpida algoritmo de hash, como uno de los SHA-2 con la familia (SHA-1 también se ha debilitado, a pesar de que no se rompe tan mal como MD5).
editar:La técnica utilizada en el enlace que he proporcionado usted participa de ser capaz de elegir dos arbitraria mensaje de prefijos y sufijos comunes, de las que se podía generar para cada prefijo de un bloque de datos que puede ser insertado entre el prefijo y el sufijo común, para producir un mensaje con la misma suma MD5 como el mensaje construido a partir de otro prefijo.No puedo pensar en una manera en que esta vulnerabilidad podría ser explotada en la situación que usted describe, y en general, el uso de un seguro tiene para autenticación de mensajes es más resistente al ataque de usarlo para firmas digitales, pero no puedo pensar en un par de vulnerabilidades, usted necesita mirar hacia fuera para, que en su mayoría son independientes de el hash que usted elija.
Como se describe, su algoritmo consiste en almacenar la contraseña en texto plano en el servidor.Esto significa que son vulnerables a cualquier divulgación de información de ataques que puede ser capaz de descubrir las contraseñas en el servidor.Usted puede pensar que si un atacante puede acceder a su base de datos, entonces el juego ha terminado, pero los usuarios preferirán probablemente si, incluso si su servidor está en peligro, que sus contraseñas no ser.Debido a la proliferación de contraseñas en línea, muchos usuarios utilizan la misma o similar contraseñas a través de los servicios.Además, la divulgación de información de los ataques puede ser posible, incluso en los casos en que la ejecución de código o ataques de elevación de privilegios no son.
Se puede mitigar este ataque de almacenar la contraseña en el servidor de hash con una muestra aleatoria de sal;almacenar el par
<salt,hash(password+salt)>en el servidor y enviar la sal para el cliente, de forma que se puede calcularhash(password+salt)para utilizar en lugar de la contraseña en el protocolo que usted menciona.Esta no la protege contra el ataque siguiente, sin embargo.Si un atacante puede oler un mensaje enviado desde el cliente, se puede hacer un diccionario sin conexión ataque en contra de la contraseña del cliente.La mayoría de los usuarios tienen contraseñas con bastante baja entropía, y un buen diccionario de cientos de miles de contraseñas existentes además de algo de tiempo al azar permuting ellos podría encontrar una contraseña dada la información que un atacante ha de oler un mensaje bastante fácil.
La técnica que proponemos no puede autenticar el servidor.No sé si esto es una aplicación web que usted está hablando, pero si es así, entonces alguien que puede realizar un DNS secuestrar ataque, o DHCP secuestro en una red inalámbrica no segura, ni nada por el estilo, sólo puede hacer un hombre en el ataque medio en el que se recogen las contraseñas en texto claro de sus clientes.
Mientras que el actual ataque contra el MD5 no puede trabajar en contra de el protocolo que usted describe, MD5 ha sido severamente comprometida, y un hash sólo de vez más débil, más fuerte que nunca.¿Quieres apostar que va a averiguar acerca de los nuevos ataques que podría ser usado en su contra y tendrá tiempo para actualizar algoritmos hash antes de que sus atacantes tienen la oportunidad de aprovechar de ti?Probablemente sería más fácil empezar con algo que es actualmente más fuerte que el MD5, para reducir sus probabilidades de tener que lidiar con MD5 ser roto más.
Ahora, si usted está haciendo esto para asegurarse de que nadie la forja de un mensaje de otro usuario en un foro o algo, entonces seguro, es poco probable que alguien va a poner el tiempo y esfuerzo en romper el protocolo que se describe.Si alguien realmente quería hacerse pasar por otra persona, que probablemente podría crear un nuevo nombre de usuario que tiene un 0 en lugar de una S o de algo aún más el uso de Unicode, y que ni siquiera se moleste en tratar de forjar mensaje y romper algoritmos hash.
Si se usa para algo donde la seguridad que realmente importa, entonces no hay que inventar su propio sistema de autenticación.Sólo uso TLS/SSL.Una de las reglas fundamentales de la criptografía es no inventar su propia.Y entonces, incluso para el caso del foro de donde probablemente no importa mucho, no va a ser más fácil usar algo que está demostrado fuera de la plataforma de rodar su propio?
Otros consejos
En este caso particular, no creo que el eslabón más débil de la aplicación está utilizando MD5 en lugar de sha. La manera en que md5 es "roto" es que dado que md5 (K) = V, es posible generar K 'de tal manera que md5 (K') = V, ya que la salida del espacio es limitado (no porque hay cualquier trucos para reducir el espacio de búsqueda). Sin embargo, K 'no es necesariamente K. Esto significa que si se sabe md5 (M + T + P) = V, puede generar P' tal que md5 (M + T + P ') = V, esta dando una entrada válida . Sin embargo, en este caso el mensaje sigue siendo el mismo, y P no ha sido comprometida. Si el atacante intenta forjar mensaje M 'con una T' marca de tiempo, entonces es muy poco probable que md5 (M '+ T' + P ') = md5 (M' + T '+ P) a menos que P' = P. en cuyo caso, tendrían bruta forzó la contraseña. Si han bruta obligado a la contraseña, entonces eso significa que no importa si se ha utilizado sha o md5, ya comprobando si md5 (M + T + P) = V es equivalente a la comprobación de si sha (M + T + P ) = V. (excepto que sha podría tomar constante de tiempo más largo para calcular, que no afecta a la complejidad de la fuerza bruta en P).
Sin embargo, dada la opción, que realmente debería seguir adelante y utilizar sha. No hay sentido en no usarlo, a menos que exista un serio inconveniente para usarlo.
Una segunda cosa es que probablemente no debería almacenar la contraseña del usuario en su base de datos en texto plano. Lo que debe almacenar es un hash de la contraseña, y luego usar eso. En su ejemplo, el hash sería de: MD5 (Message + tiempo + MD5 (contraseña)), y se puede almacenar con seguridad MD5 (contraseña) en su base de datos. Sin embargo, un atacante robar su base de datos (a través de algo así como la inyección de SQL) todavía sería capaz de falsificar mensajes. No veo ninguna forma de evitar esto.
La respuesta de Brian abarca los temas, pero yo creo que hay que explicar un poco menos informa extensamente
Está utilizando el algoritmo de cifrado mal aquí
MD5 es mal aquí, SHA1 es incorrecto utilizar aquí Sha2xx es incorrecto usar y madeja es incorrecto utilizar.
Lo que se debe utilizar es algo como RSA .
Me explico:
Su control seguro es el envío de la contraseña de manera efectiva hacia fuera para que el mundo vea.
Usted menciona que su hash es "tiempo de carga útil + + contraseña", si un tercero obtiene una copia de su carga útil y conoce el tiempo. Se puede encontrar la contraseña (usando una fuerza bruta o ataque de diccionario). Por lo tanto, es casi como si va a enviar la contraseña en texto claro.
En lugar de esto, usted debe mirar a un criptografía de clave pública tiene su envío del servidor las llaves públicas a sus agentes y los agentes tienen cifrar los datos con la clave pública.
No hay hombre en el medio será capaz de decir cuál está en los mensajes, y nadie será capaz de forjar los mensajes.
En una nota lateral, MD5 es bastante fuerte la mayor parte del tiempo.
Depende de lo valioso que el contenido de los mensajes son. La familia SHA es demostrablemente más seguro que MD5 (donde "más seguro" significa "más difícil de falsificar"), pero si sus mensajes son actualizaciones de Twitter, entonces es probable que no le importaba.
Si esos mensajes son la capa IPC de un sistema distribuido que se encarga de las transacciones financieras, entonces tal vez se preocupa más.
Actualización:? Debo añadir, también, que los dos algoritmos de resumen son esencialmente intercambiables en muchos aspectos, por lo que la cantidad más problemas sería realmente a utilizar el que más seguro
Actualización 2: esta es una respuesta mucho más a fondo: http: //www.schneier. com / ensayo-074.html
Sí, alguien puede enviar un mensaje y un hash correcto sin conocer la contraseña compartida. Sólo tienen que encontrar una cadena que hashes en el mismo valor.
¿Qué tan común es que? En 2007, un grupo de los Países Bajos anunció que había predicho el ganador de la elección presidencial estadounidense de 2008 en un archivo con el valor hash MD5 3D515DEAD7AA16560ABA3E9DF05CBC80 . Luego crearon doce archivos, todos idénticos excepto por el nombre del candidato y un número arbitrario de espacios siguientes, que hash a ese valor. El valor hash MD5 es inútil como una suma de comprobación, porque hay demasiados archivos diferentes dan el mismo resultado.
Este es el mismo escenario que la suya, si estoy leyendo su derecha. Basta con sustituir "el nombre del candidato" con "contraseña secreta". Si realmente quiere estar seguro, probablemente debería utilizar una función hash diferente.
Sí, vale la pena que preocuparse de qué hash para usar en este caso. Veamos el modelo de ataque primero. Un atacante no sólo podría tratar de generar valores md5 (M + T + P), pero también podría tratar de encontrar la contraseña P. En particular, si el atacante puede recoger tupels de valores M i , T i , y el MD5 correspondiente (H i , T i , P), entonces él / ella puede tratar de encontrar P. Este problema hasn' t sido estudiados tan extensamente para las funciones de hash como la búsqueda de colisiones. Mi acercamiento a este problema sería la de tratar el mismo tipo de ataques que se utilizan contra el cifrado por bloques: por ejemplo, ataques diferenciales. Y puesto que MD5 ya altamente susceptible a ataques diferencial, ciertamente puedo imaginar que tal ataque podría tener éxito aquí.
Por lo tanto te recomiendo que utilice una función hash MD5 más fuerte que aquí. También recomiendo que utilice HMAC en lugar de sólo MD5 (M + T + P), porque HMAC ha sido diseñado para la situación que usted describe, y en consecuencia se ha analizado.
No hay nada inseguro acerca del uso de MD5 de esta manera. MD5 solamente se rompió en el sentido de que, hay algoritmos que, dado un montón de datos A de datos adicional B se puede generar para crear un hash deseado. Es decir, si alguien conoce el hash de una contraseña, que podían producir una cadena que dará lugar a que hash. Sin embargo, estas cadenas generadas son normalmente muy largo, así que si se limita contraseñas a 20 o 30 caracteres que todavía está probablemente seguro.
La razón principal para usar SHA1 sobre MD5 es que las funciones MD5 se están eliminando. Por ejemplo, la biblioteca Silverlight .Net no incluye el proveedor de MD5 criptografía.
MD5 proporcionar más de colisión de SHA, que significa que alguien puede conseguir realmente mismo hash de palabra diferente (pero es raramente).
familia SHA ha sido conocido por su fiabilidad, SHA1 ha sido estándar en el uso diario, mientras que SHA256 / SHA512 era un estándar para el gobierno y los bancos electrodomésticos.
Para su sitio web personal o foro, le sugiero que usted considere SHA1, y si crea una más grave como el comercio, le sugiero que utilice SHA256 SHA512 (familia SHA2) /
Tanto AMD MD5 SHA-1 tienen debilidades criptográficas. MD4 y SHA-0 también se vean comprometidas.
Probablemente se puede utilizar con seguridad MD6, Bañera de hidromasaje, y RIPEMD-160.
Vea el siguiente PowerPoint de la Universidad de Princeton, desplazarse hasta la última página.
No voy a comentar sobre el MD5/SHA1/etc.problema, así que tal vez usted va a considerar esta respuesta discutible, pero algo que me divierte muy ligeramente cuando el uso de MD5 et al.para el hashing de contraseñas en las bases de datos viene.
Si alguien hurgando en su base de datos, entonces podrían muy bien quiera ver el hash de contraseña, pero es igual de probable que van a querer robar información personal o cualquier otro dato que pueda haber por ahí en otras tablas.Francamente, en ese caso, usted tiene el pez más grande para freír.
No estoy diciendo que ignorar el problema, y como dije, esto en realidad no tiene mucho que ver si o no usted debe utilizar MD5, SHA1 o lo que sea de hash de las contraseñas, pero tengo cosquillas de un color ligeramente rosado cada vez que leo a alguien haciendo un poco demasiado molesta contraseñas en texto plano en una base de datos.
