Se supone que MD5 es un cifrado de una sola dirección no?
#32 Yo es que recuerdo que en seguridad informática estuvimos hablando acerca de MD5 y el profesor nos comentó eso que, es una clave de una sola dirección y que además no se conocer aún los números primos que la geneneran, solo eso xd.
#31 MD5 no es un cifrado, sólo es un algoritmo de reducción (o digest.) El cifrado implica que se puede descifrar.
#32 MD5 es vulnerable MÁS ALLÁ DE LA FUERZA BRUTA.
Ya no es sólo para password, sino como digest en general está acabado, debido a su vulnerabilidad en segunda preimagen.
#33 ni puto caso a tu profesor porque oye campanas y no sabe dónde.
En MD5 no intervienen números primos y, si intervinieran, se conocerían de sobra los números primos que la generan (si no, no se podrían generar MD5...)
Probablemente tu profesor se refería a RSA: http://es.wikipedia.org/wiki/RSA
En la criptografía es MUY importante que todo el mundo conozca todo (excepto las claves privadas de sus usuarios, obviamente) por dos razones:
1. Así todo el mundo puede generar (y comprobar la autenticidad) de los mensajes/digest/whatever generados por los correspondientes algoritmos.
2. La seguridad por oscuridad no es seguridad, sino falsa sensación de esta.
Aprovecho para mencionar bcrypt y scrypt, pensados específicamente para el tema que estamos tratando (es decir, hashing de claves.)
#30, muchas gracias,
Maldito #34 y #36, se me ha adelantado tanto con la info de md5 como con la recomendación de bcrypt xDD. De todas formas, aquí tenéis un artículo sobre bcrypt muy explicativo y sencillo, en el que además se explica por qué no usar md5, sha, etc.
Me interesa este thread por que cada día hago páginas web mas complejas, pero hay una cosa sobre SQL inyection que no me aclaro muy bien.
Si bien en mysql con mysql_real_string_scape vas casi de sobra, como es posible de todos modos que un usuario malintencionado logre hacer sqlinyection si el no conoce nombre de tablas...
Es imposible, mirando mis páginas web que atacan a base de datos no muestro en ningún momento nombre de tablas, solo valores y nada mas....algún experto por favor para responderme.
Gracias
#38 no es necesario, porque por ejemplo cuando haces un SELECT lo que quieres es que te devuelva algo, si no es que está mal, entonces el SELECT de la tabla lo haces tú, y no desde fuera.
SQL injection se aprovecha de que puedas meter datos en campos, que no se "parsean" para mezcladas con tus sentencias devuelva algo correcto metiendo cadenas de caracteres que completen la query para tales efectos.
Aqui tienes unos ejemplos http://foro.elhacker.net/tutoriales_documentacion/tutorial_de_inyeccion_sql_sql_injection-t98448.0.html
A mi me tienen dicho que md5 no tiene ninguna vulnerabilidad conocida, pero que obivamente es mas seguro utilizar sha1 o sha2, aun asi md5 con salt deberia de ser seguro de sobra.
hash = md5 ( ( password + salt ) + salt )
Un último intento...
1º De una función hash IRREVERSIBLE JAMÁS podrás averiguar cuál fue la cadena original que produjo un hash determinado ( podrás obtener una lista de cadenas que dan el mismo hash que tienes, que se llaman "colisiones" ).
2º Cuando se dice que MD5 (y cia) no es seguro NO ES porque alguien consiga un hash de una password y pueda obtenerla (repito, obtener una cadena que produzca el mismo hash, no necesariamente la contraseña original) haciendo:
while( md5(permutation) != hash )
permutation=next_permutation();Esto es un ataque de pre-imagen de complejidad computacional O(2n) En el caso de MD5 serían 2128 = 340282366920938463463374607431768211456 operaciones, lo que significa que si la cadena original es "medianamente" larga no vas a encontrar una colisión en la vida. (Desde 2009 hay un ataque de preimagen contra MD5 que rebaja de 2128 a 2123.4, pero sigue siendo un huevo). Las tablas Rainbow se crearon para acelerar este ataque precomputando hashes de cadenas "comunes", pero no encontraréis tablas rainbow para contraseñas de más de X caracteres porque sencillamente no son computacionalmente tratables.
Luego hay otro ataque de colisión ( el "peligroso" ) que consiste en ir añadiendo o quitando ciertos bits a dos documentos hasta que sus hashes colisionen (esto se llama ataque de prefijo). Es lo que supuestamente han usado los de Flame, y que en MD5 se puede conseguir desde 2007 con 250 operaciones de forma teórica (y ya en 2008 apareció un ataque real). Este ataque es el que se usa para falsificar firmas digitales.
Y tb está el "ataque" de cumpleaños, que en realidad no es un ataque sino una propiedad matemática que dice que si coges dos cadenas al azar la probabildiad de que sus hashes colisionen es de 1.2*(2n/2), en el caso de MD5, 1.2(264).
RPV: Para almacenar contraseñas hasheadas, la resistencia a la colisión no es necesaria, pero si podéis pasar de MD5, mejor. (Eso sí, meterle un buen SALT y si es posible en posiciones arbitrarias, no al principio o al final de la cadena)
Salu2 
#40 http://www.win.tue.nl/hashclash/rogue-ca/
No es directamente aplicable a passwords pero sí es vulnerable. Es peligroso usar MD5 para comprobar integridad.
Por otro lado: confíais demasiado en las salts. Es un arma de doble filo confiar en su seguridad. Si han conseguido tus hashes, ¿por qué no iban a conseguir tu salt, el número de iteraciones que realizas el hashing, etc.?
Entonces, que recomendaríais hacer?
Yo normalmente uso sha1(string) y me olvido de todo lo demas, y siempre he pensado que, en caso de ponerme "nazi" con el tema, usaria 2 encriptadores distintos, del tipo
sha1(crypt(string,claveSecreta)) ;
Debido a este tema, he estado buscando en php.net y no recomiendan MD5 ni SHA1 para las claves 
pero por que dicen que la velocidad de calculado de cada uno es muy rapida, y cada vez es mas facil sacarlos por fuerza bruta.
Mirando las opciones, creo que empezare a usar sha512 e iré probandolo proximamente, a ver que tal va
#45 en efecto, SHA-1 también se considera débil.
Yo recomiendo cualquier algoritmo pensado para claves (véase #36) Vale que SHA-256/512 aún no son vulnerables ni prácticos de atacar pero... ¿Y si algún día lo son? IMHO, nada mejor que un hash pensado para passwords.
Me sonaba haberlo comentado pero parece que no: no sé si bcrypt o scrypt (o ambos, no recuerdo bien) necesitan de 32Mb de memoria para almacenar tablas, que puede ser un problema en sistemas embebidos.
#46 puestos a usar algo distinto, estoy leyendo y me voy a pasar a bcrypt.
A quien le interese como implementar esto en php, os pongo el siguiente enlace: http://phpmaster.com/why-you-should-use-bcrypt-to-hash-stored-passwords/
#48 Jajaja, gracias pero no. Las fechas las he tenido que consultar y otras cosas revisarlas porque es algo que lees y tal pero se olvida (más con mi fish-mem).
Un salt es una cadena "aleatoria" que le añades a la contraseña antes de calcular el hash para "dificultar" un ataque de pre-imagen. Ese salt normalmente tienes que almacenarlo, así que no es conveniente hacerlo junto al hash
Luego está la forma de calcular el hash usando el salt, que es cuestión de echarle imaginación:
hash = md5(salt+pass)
hash = md5(pass+salt)
hash = md5(md5(pass)+salt)
hash = md5(md5(pass)+md5(salt))
hash = md5(salt+md5(pass+md5(salt))+pass+md5(md5(pass)))
ETC.
Así que a priori, con el hash y el salt usado, el atacante todavía tendría que averiguar el método usado para hashear...
Salu2
2 meses después
Bueno, revivo el hilo para pedir a los expertos consejos sobre cómo aislar y proteger correctamente las consultas SQL (que yo creo que es por donde más nos pueden dar por culo) en PHP.
#50 yo uso PDO+ htmlspecialchars con ENT_QUOTES para TODO lo que entra por forms a la aplicación.
No he sido capaz de inyectar nada con eso, pero claro no soy un experto hacker xD asi que imagino no significa que sea seguro.
Yo tengo otra pregunta acerca de cómo guardar las contraseñas. A veces me pongo muy sibarita con este tema y me rayo.
Pongamos que el MD5 es inseguro. Haciendo un hast como indica #49, tal que
hash = md5(salt+md5(pass+md5(salt))+pass+md5(md5(pass)))
no afecta muy negativamente al servidor hacer tanto md5? También vi, no se si en este hilo o en otro, que un usuario usaba una iteración de 100 veces el md5 para guardar una contraseña, si a esto encima le añades un salt... la contraseña sería absolutamente segura? Partiendo de la base de que no pueden acceder jamás al archivo php con el que generas el algoritmo.
Lo comento por si más adelante me surge la posibilidad de hacer un proyecto tocho en el que la seguridad sea mega importante. Todo lo que he hecho hasta ahora han sido "intranets normales", con sistemas de usuarios normales, pero todo más o menos privado, nunca algo global y abierto. Salvo en una ocasión, que "me curré" un guardado de contraseña algo más seguro.
Así pues, me interesaría saber cómo lo hacéis vosotros en el caso de que hubiera que desarrollar una aplicación con la máxima seguridad que seamos capaces de crear y que no colapse el servidor. (seguridad extrema + rendimiento)
Gracias :si:
#52 el servidor ni lo nota, de hecho phpbb3 hace algo similar, con unas 10000 vueltas si no me equivoco a md5+salto y no ponen pegas en ningún sitio xD
Siempre puedes usar tablas hash
Edit: y no, md5+salt no es seguro si consiguen sacarte el salt, dado que md5 no es seguro, simplemente le pones un cerrojo más.
#52 Yo por ahora lo hago en MD5. Pienso que si no pueden acceder a las contraseñas encriptadas (robar la base de datos, vamos), ni al PHP que las genera, no van a crackearlas.
Respecto al rendimiento, pues cuantas más iteraciones y más complicaciones más rendimiento del servidor se chupa. Quizá en un proyecto pequeño el impacto sea inapreciable y en uno grande, pues quizá notes algo si tu máquina es basurota.
#53 gracias por la aclaración. Intentaré buscar lo que hace WordPress para guardar las contraseñas, porque quedan todas más o menos así: $P$BWMtd4iaIacEh0{P97zXRIMST3K.Pi. xD
#54 MD5 es seguro, sí y no. El problema es que ya hay una base de datos muy grande de comparaciones, y aunque no lo creas, el 90% de usuarios ponen contraseñas normales, fácilmente crackeables a menos que sean totalmente inventadas. En cuyo caso también son crackeables a base de colisiones. MD5 a pelo está bien para aplicaciones pequeñas y privadas, pero en el momento que sea algo abierto... siempre es bueno potenciar al máximo tu seguridad.
Para el siguiente sistema de usuarios que tenga que hacer, sea de la magnitud que sea, intentaré empaparme bien de los métodos actuales y más seguros, así como el rendimiento del servidor. Informaré por aquí intentando crear un post apañaete que nos sirva a todos.
#55 Entonces tira de esto: http://bcrypt.sourceforge.net/
Que por cierto, viene con PHP 5.3 incluido ya :3
#51 htmlspecialchars no esta diseñado para impedir sqli y en todo caso no te protege por ejemplo si el dato es un entero. PDO hasta donde yo se es seguro.
#57 te protece de caracteres especiales y de comillas, que es practicamente lo que usa pdo->quotes asi que indirectamente tambien lo evitas
Vamos por partes, si decimos que PDO es seguro es por que usa "prepared statements" (no se como se dice en español). Los datos y la consulta estan totalmente separados y es imposible realizar sql injection de primer nivel de ninguna manera. Luego, la funcion que usas no te protege de sqli, solo de ciertos tipos y de casualidad. Esa funcion es para filtrar el "output" de la base de datos a un navegador.
Edit: La verdad es que me no me habia dado cuenta de los efectos negativos que tiene ademas usar htmlspecialchars para introducir informacion en la db, metes informacion en la db con html entities que puede ser un grave problema a la hora de, por ejemplo, buscar la informacion.
#59 pero no es seguro para injection solo con eso, ya puse un enlace de stackoverflow.
Y eso de que "por casualidad", que no puedas usar comillas en una cadena no tiene nada de casualidad.
El problema que puede tener en búsquedas lo solucionas tratando igualmente lo que estás buscando.