Formulario seguro (con encriptación)

cnavast · #1 (**permalink**) 13/07/2012, 14:54

Hola,

Estoy haciendo un login seguro con PHP y para evitar los ataques man in the middle voy generando un token aleatorio en el servidor que paso al cliente cada vez que este entra a login.php. Desde ahí cuando el usuario mete su password se pasa por el típico js de validación del formulario que genera un hash MD5 de la concatenación del token y el md5 de la contraseña introducida [ md5(token+md5(password)) ] y ESO es lo que quiero que se envíe, y ya en el server hacer la misma encriptación y comprobar ambos hashes.

De esta forma, lo que pretendo es que en NINGÚN MOMENTO esté viajando entre el ordenador y el router la contraseña del usuario "desnuda".

¿Cuál es el problema? Pues que mientras el campo de tipo password donde el usuario ha escrito su contraseña esté dentro de la etiqueta form, por mucho que encripte TAMBIÉN se va a mandar ese campo, o sea que estamos en las mismas... os preguntaréis: ¿por qué no sacarlo del form y coger su valor con getElementById? Pues porque entonces los exploradores no muestran la opción de "Guardar contraseña" y yo quiero que lo hagan :(

¿Qué se os ocurre?
Thanks!

fjrueda · #2 (**permalink**) 13/07/2012, 15:06

cnavast

Si bien se puede usar como lo plantea, es mejor y mas segurito enviarlo dentro del formulario y con el metodo post, pero aun asi usted creo que lo esta buscando es lo que explican en este link >> http://www.webtoolkit.info/javascript-base64.html

Espero que le sirva.

Dradi7 · #3 (**permalink**) 13/07/2012, 15:22

Bueno según lo que entiendo no quieres enviar el campo password a través de las peticiones request, de todas maneras la contraseña va a ser enviada a traves del request.

Si lo que quieres es seguridad para que no sepan cual es la contraseña debes trabajar de esta manera.

1.- La Contraseña debe estar guardada en el servidor encriptada preferible que sea de la siguiente forma SHA1(TOKEN + PASSWORD), es decir en tu Base de Datos.

2.- El Token debe estar guardado en un archivo aparte o en una clase que esta en tu servidor, el token debe contener de preferencia para mayor seguridad números, letras, otros caracteres y que sean Mayúsculas o Minúsculas.

3.- No hay que realizar como lo estas planteando en encriptar la contraseña en el lado Cliente y luego Obtener la Contraseña en el lado del Servidor y encriptarla y validarla ¿Porque? Esto haria que el hacker podria saber el algoritmo de encriptacion y a traves de Rainbow Tables obtener tu password

4.- La forma correcta de hacerlo es enviar tu password que el servidor lo encripte, luego toma la contraseña ya encriptada de tu base de datos y compararla de tal manera que sea un poco difícil poder saber si realmente lo que se esta enviando es la contraseña correcta.

Pero a pesar de todo aun la contraseña no es aun segura, te recomiendo que leas este articulo el cual explica una encriptación de contraseña a un nivel muy seguro.

http://net.tutsplus.com/tutorials/ph...asswords-safe/

cnavast · #4 (**permalink**) 13/07/2012, 15:41

Gracias a ambos por responder, pero parece que me he explicado mal. Yo ya tengo el sistema de hashes y passwords seguro, pero ahora lo que me interesa es evitar otro tipo de ataque: el man in the middle. Para eso quiero evitar a toda costa mandar desde el PC al router la contraseña sin haberla encriptado antes.
El problema es simple y llanamente que para hacer esto tengo que sacar el campo type=password FUERA del form (si no se enviará hacia el router, justo lo que quiero evitar) y lo que pasa es que al hacer esto ya no aparece lo típico de recordar contraseña. Eso es todo.

Dradi7 · #5 (**permalink**) 13/07/2012, 16:08

Bueno la única manera que veo posible esto evitar es usando Certificados SSL, la cual validen de una forma mas segura aun

cnavast · #6 (**permalink**) 13/07/2012, 18:26

SSL sin duda me ahorraría muchos problemas, sí... pero el cliente no quiere pagar tanta pasta por el server :(

Panino5001 · #7 (**permalink**) 13/07/2012, 18:47

Si no puede o quiere instalar un certificado ssl, antes que el mecanismo que propones creo que mejor sería loguearse con herramientas como las que proveen facebook, twitter (pinterest, por ejemplo, usa cualquiera de las 2), google friend connect u openid.

dontexplain · #8 (**permalink**) 14/07/2012, 01:44

Si envias por POST el hash el hash está desnudo, si envías el password el password queda desnudo. La única forma es simular SSL.

Para ello has de usar una key única a la recarga de la página, que será generada de PHP. Esa key servirá de clave para encriptar el password. Como la clave se genera cada vez que se recarga es imposible averiguar cual es.

A la llegada del password se descifra con esa misma clave almacenada en $_SESSION y se procede a la autentificación corriente.

Un saludo.

Panino5001 · #9 (**permalink**) 14/07/2012, 03:24

Cita:

Iniciado por dontexplain

Si envias por POST el hash el hash está desnudo, si envías el password el password queda desnudo. La única forma es simular SSL.

Para ello has de usar una key única a la recarga de la página, que será generada de PHP. Esa key servirá de clave para encriptar el password. Como la clave se genera cada vez que se recarga es imposible averiguar cual es.

A la llegada del password se descifra con esa misma clave almacenada en $_SESSION y se procede a la autentificación corriente.

Un saludo.

Lo que estás haciendo es cifrar en el cliente; en otras palabras, estás mostrando el camino para revertir el proceso y, en consecuencia, estás en la misma, sólo dificultaste un poco las cosas. La delegación del proceso en sistemas como facebookConnect, twitterConnect, o similares funciona de la misma manera en que lo hacen los carros de compra integrados con PayPal: llevan el proceso de intercambio de información sensible a un website con ssl.

dontexplain · #10 (**permalink**) 14/07/2012, 03:39

Cita:

Iniciado por Panino5001

Lo que estás haciendo es cifrar en el cliente; en otras palabras, estás mostrando el camino para revertir el proceso y, en consecuencia, estás en la misma, sólo dificultaste un poco las cosas. La delegación del proceso en sistemas como facebookConnect, twitterConnect, o similares funciona de la misma manera en que lo hacen los carros de compra integrados con PayPal: llevan el proceso de intercambio de información sensible a un website con ssl.

No es la mejor alternativa y lo se.

No obstante veo poco probable en la práctica que alguien pueda revertir un proceso de cifrado en AES a 256 bits pese a que el algoritmo de generación de clave (lo que llamas el camino) se conoce sobradamente ya que AES es un estándar que está publicado.

cnavast · #11 (**permalink**) 14/07/2012, 04:51

Ya, también pensé en FBConnect y demás pero el cliente no quiere...
Y a dontexplain: eso es más o menos lo que hago. Mira, cada vez que se entra al login se renueva $_SESSION["token"] con una cadena aleatoria que se pasa mediante campo hidden al cliente. La idea es que el cliente mande al servidor este hash:
md5(token_del_campo_hidden+md5(password_escrita_en _el_campo_password))
Y luego en el servidor se hace md5($_SESSION["token"]+md5(password_de_la_DB)) y se comprueban ambas cadenas.
Así, si hay un ataque Man In the Middle que intercepta ese hash dará igual, porque cuando lo intente usar el hash del servidor ya habrá cambiado (porque $_SESSION["token"] se habrá renovado).
Y después de haber pensado y desarrollado esto me jode que se esté mandando también al router la contraseña "desnuda" simplemente porque está dentro de la etiqueta <form>... y si saco ese input del form (para que no se mande) entonces no aparece lo de recordar contraseña...
Si no hay solución pues se lo pongo al cliente tal y como está y oye, que él valore...

dontexplain · #12 (**permalink**) 14/07/2012, 06:05

Cuando se realiza un evento de tipo submit se envían todos los campos salvo los que estén disabled. El navegador muestra la opción de guardar password a los campos de password que efectivamente se enviaron. No obstante, guardar la contraseña en el navegador no es una muy buena opción. Replantea aumentar el tiempo de expiración de las sesiones.

Un saludo.

cnavast · #13 (**permalink**) 14/07/2012, 06:18

Ok, muchas gracias!
Lo del disabled no lo sabía. He probado que cuando se pulse enviar el JS ponga en disabled el campo password y efectivamente éste no se manda, aunque tampoco me aparece lo de recordar contraseña, pero bueno, ya me doy por vencido!

Muchas gracias a todos!

dontexplain · #14 (**permalink**) 14/07/2012, 06:34

Cita:

Iniciado por cnavast

Ok, muchas gracias!
Lo del disabled no lo sabía. He probado que cuando se pulse enviar el JS ponga en disabled el campo password y efectivamente éste no se manda, aunque tampoco me aparece lo de recordar contraseña, pero bueno, ya me doy por vencido!

Muchas gracias a todos!

Porque recordar contraseña aparece cuando se envía. La única forma de modificarlo sería cambiando de alguna forma las circunstancias del evento o el comportamiento por defecto del navegador. Desconozco cómo se hace.

KDC85 · #15 (**permalink**) 31/10/2013, 00:27

Yo hago una pregunta y si se envia por ajax solo los campos que se desen incluyendo la opcion de recordar no seria una buena opcion?, asi solo se mandarian los campos que uno desea y en este caso solo seria el hidden y el username bueno agregando un script para lo del recordar.