Enviando passwords de forma segura con MD5 y PHP3

Por
Amigos, si no limpian el campo password no sirve el método propuesto ya que el password se transmite por la red en texto plano!

Por
¡Es un buen metodo! y felicito al que publico y/o lo creo por que demuestra interes en el tema, mucho mas que aquellos que solo se dedican a criticar y no aportan nada. En cuanto al metodo y en mi opinion personal es bueno para proteger las contraseñas de tus usuarios y que no sean descubiertas por atancantes a la base de datos o por otras personas qu tengan acceso a la misma, como compañeros de trabajo o algo asi, pero no ofrece seguridad a nivel de Red, ya que para un snifer es indiferente si la contraseña viaja sifrada o no, solo necesita escuchar la red y replicar la misma informacion, si al contraseña va cifrada y es interferida tengo su resultado, para que necesito la clave original, el servidor no entiende que se le envie la clave original, el servidor entiende que ecibe una clave cifrada y eso es lo que le envio, de igual manera sucede si le envio la clave sin cifrar y es cifrada en el servidor.

Repito, Felicito a la persona que publico este articulo, y hago enfasis en su utilidad para impedir que la contraseña de un usuario sea leida por personas que tengan acceso a la base de datos, no funciona a nivel de red, para la seguridad a nivel de Red se requie un canal seguro como con https, que proporciona como una especie de canal invisible a los snifer entre el cliente y el servidor

Por
Creo que es una vergüenza que alguien que parece de seguridad y que seguro que aprecia la informática diga: \\\"dejad de reinventar la rueda\\\". Si por algo la informática es tan rica hoy en dia es justo por \\\"reinventar la rueda\\\". Si tienes conocimiento de la evolución de la informática, sabrá que han surgido lenguajes como php, java habiendo cgi + C, o C respectivamente. \\\"Reinventaron la rueda\\\", pero haciendola válida para todos los coches y que se pudiera trabajar con ella más fácilmente.
Bien, dicho esto, solo apuntar que este script no sirve de nada porque un sniffer tendria los datos del hash y del numero, con lo que no te sirve.
Aqui el proposito es lograr una conexion segura sin htpps (claro que es lo ideal, pero paga tu eso).
Desde luego enviar la contraseña encriptada en md5 en un gran paso para que un sniffer no sepa la contraseña original, sino solo el hash.
Ahora, lo del numero es una tonteria porque un sniffer tambien te va a coger el numero. Y coge y envia el has con el numero ese y listo.
La cuestion seria obligar al que envia la información a usar un numero en la codificación. Asi, si un sniffer lo intenta, el servidor no le hará caso ya que el numero que le manda el usuario no es el numero que el servidor queria.
El problema de esto seria que habria que almacenar los numeros en alguna base de datos (mysql), y luego borrarlos. Habria que asociarlo con una id o con su ip, da lo mismo. La cuestion es que el servidor imponga un numero al azar.
Luis, este metodo que progongo supongo que si que es seguro. El sniffer solo tiene un hash o varios hash con un numero que el no sabe cual es. Si esto lo hacemos con numero del 1 al 10000 o mas, tendria que almacenar cientos de hashes y hacerlo en el tiempo que se está autentificando el usuario.
Es decir, que estamos ante un sistema seguro!

Por
Tu respuesta titulada \"pequeña gran contradición\" no es tal, y sólo es fruto de no saber cómo funcionan las funciones hash de una sola vía.

Lo que el autor ha querido decir con eso es que, conociendo un resumen criptográfico (hash) de una cadena, generar otra que tenga el mismo resumen (colisión) es difícil. Y dicha dificultad reside en la cantidad de hashes diferentes que puede generar la función, que en el caso de MD5 es de dos elevado a 128. Si una persona conoce un resumen criptográfico y quisiera conocer cuál es la cadena que ha dado lugar a ese hash, necesitaría en el peor de los casos 2 elevado a 128 intentos para conseguirlo peeeero, eso no le garantiza obtener la misma cadena (lo cual es casi imposible porque es de una posibilidad frente a infinito) sino que obtendrá otra cadena que produce el mismo hash. No obstante, a efectos de la autenticación sería válido ya que el servidor se basa en el hash obtenido, no en la cadena que lo ha generado.

En resumidas cuentas: El autor ha escrito mal el texto al hablar sobre la \"imposibilidad de encontrar dos cadenas de texto que generen el mismo resultado\". Sí que se puede, y el caso peor está calculado. Lo que sucede es que es muy difícil (cada día menos debido a los ordenadores más rapidos). Por otro lado, cometes un error al tragarte este pastiche sobre autenticación y seguridad.

Por
Hola, me parece bárbaro el artículo y muy bueno el ejemplo, pero me gustaría que me expliques un poco la parte en que escribes:

-“ y también la imposibilidad de encontrar dos cadenas de texto que generen el mismo resultado.”

Te contradices con:

-“ para comprobar si el password es correcto, se cifra de la misma manera y se comparan las formas cifradas.”

¿Si es imposible que de dos cadenas de texto se generen el mismo resultado, como hago para comparar la clave enviada y la que ya esta almacenada en el host?

¿ah? L

Saludos.

Por
En respuesta a Loksly , tu solución es igual de inútil. Da lo mismo que el nº aleatorio se genere en el cliente o en el servidor. La cuestión es que es enviado y puede ser interceptado por un tercero que esté escuchando la red. Luego sólo tiene que repetir lo que tenía previsto hacer el cliente y hacerse pasar por él.

Mirad (y esto va para todos), las técnicas basadas en cifrar simétricamente a base de secretos, en donde dichos secretos viajan por la red, no tienen sentido.

Toda esta tontería de usar funciones hash en el lado del cliente no protege contra nada. El propio protocolo HTTP incorpora la posibilidad de usar MD5 para cifrar los passwords en el navegador (la famosa \"autenticación digest\"). Y en la especificación se deja claro que ese método es una medida de seguridad no confiable.
Si realmente queréis seguridad dejad de reinventar la rueda (y lo que es peor, sin saber) y centraos en los certificados digitales con su correspondiente respaldo de terceros (Verisign y cia). El resto son ganas de perder el tiempo y, lo que es peor, de crear una falsa imagen de seguridad.

Por
No tiene ningún sentido utilizar este sistema, pues no protege contra reenvío. Sería mejor que el número aleatorio se enviase desde el servidor, se almacenase en una variable $_COOKIE. Entonces en el lado del cliente se concatenaría el número aleatorio con el password y se enviaría. En el lado del servidor se recuperaría la variable "número aleatorio" almacenada en el array $_COOKIE y se simularía el proceso realizado en el cliente. Esta comprobación sería mucho más segura que la mostrada por el artículo.

Por
POr lo visto este articulo es muuuuuy pero muyyyyyyy viejo, ya que php 4 y 5 incorpora la funcion md5... pero sirve de algo el javascript aqui. algo mas de seguridad ya que se envia desde el cliente la contraseña encriptada.

Por
POr lo visto este articulo es muuuuuy pero muyyyyyyy viejo, ya que php 4 y 5 incorpora la funcion md5... pero sirve de algo el javascript aqui. algo mas de seguridad ya que se envia desde el cliente la contraseña encriptada.

Por
XD La verdad es que es un poco costra. Le faltan \\\\\\\";\\\\\\\" en la primera función y, además, ¿Para qué envía la contraseña? PHP 4 y 5 tienen la función MD5() hay que actualizar el sistema. El hecho de codificar la contraseña del lado del cliente tiene como objetivo el enviar el HASH y no el Password para que no sea descifrado. De todos modos, a la hora de validar en el servidor, no solo necesitaremos el hash.
Este código solo me sirve para codificar en md5 del lado del cliente. Ahora me las apañaré para que quién tenga solo el login y el hash se coma los mocos.

Por
Esta guia simplemente no sirve para nada, JAMAS se debe dejar la validacion y manipulacion de datos del lado del cliente (javascript) ya que esto es muy facilmente alterable.

lo mejor es, ya que en php 3 no existe la funcion md5, usar una aplicacion externa q' devuelva el hash, dentro del codigo php.

Simplemente el nombre de este tutorial deberia ser, "Enviando passwords de forma insegura e ineficiente con JS y PHP3"

Por
Aqui les tengo un modificacón de su codigo que funciona y tiene una burla a quien se atrva a interceptar los datos.

form.html
-------------




function calculaMD5() {
passmd5 = hex_md5(document.forms["login"].elements["password"].value);
document.forms["login"].elements["password"].value = "Jodete No Hay Clave";
document.forms["login"].elements["password2"].value = passmd5;
document.forms["login"].submit();
}





Usuario:
Password:





login.php
------------




Luciano Lagassa
LAGA Systems - Soluciones Informaticas
Armstrong Santa Fe Argentina
http://www.laga.co.nr
http://lucianolagassa.no-ip.org

Por
el ultimo codigo que pusiero dicen que el password no se envia y si se envia agan la prueba primero yo lo e provado y si envia el password

Por
como se cifran los formularios con md5 ? gracias

Por
Vaya truño de web de PHP. Pongo un código de 100 líneas y no lo acepta.

Y encima ese código está copiado de librerias del PHP antiguo. Lo menos que se puede hacer es citar la fuente.

A ver si tenemos un poco de ética y no somos tan FARSANTES.

Y poner un formulario en condiciones para postear código, gurús de pacotilla