Login seguro sin SSL

[Tusade]

Hola, creo que el título de mi post resumen mi pregunta. Lo que no sé es si estoy en el subforo adecuado.

Tengo una aplicación web con Servlets, MySQL y JSP, donde se hace un login con usuario y contraseña.

El problema es que quiero protegerme de que alguien capture la contraseña y el email, y usurpe un usuario. Y no sé como hacerlo.

Me han dicho que haga un hash (¿SHA256?) de las contraseñas en Javascript desde el cliente, pero eso es una chapuza, porque si alguien captura la contraseña, la va a capturar igual.

Entonces, ¿cómo lo hago? He estado mirando esta página:

http://www.securityartwork.es/2012/03/13/metodo-de-login-seguro-sin-ssl/

Y me ha llamado la atención cuando dice:

La solución que creo más segura es la de “simular” la conexión SSL mediante un par de claves pública/privada por petición. De esta manera el servidor mandará la clave pública, que le servirá al navegador para cifrar la información, y guarda la clave privada, que sólo sirve para descifrar esa información. Para realizar esto haremos uso del Javascript de forma similar a la anterior. La diferencia es que esta vez cuando el cliente (navegador web) haga la petición a la pantalla de login, el servidor generará un par de claves nuevas.

Pero no entiendo lo que quiere decir, ¿algún alma caritativa me lo explica?

[Xerelo]

Pues es lo mismo que la conexión SSL pero sin que la gestione el servidor, lo gestiona tu aplicación.

El cliente hace una petición al servidor, y este le devuelve una clave pública. El cliente la utiliza para encriptar el mensaje y así se envía al servidor. El servidor recibe el mensaje cifrado y usa la clave privada para obtener el mensaje cifrado.

¿Existe alguna razón por la que no puedas usar una conexión SSL?

[Tusade]

Las conexiones SSL cuestan dinero, o eso tengo entendido.

Voy a informarme sobre el tema de las claves para simular una conexión ssl.

[Tusade]

Iniciado por Xerelo

El cliente la utiliza para encriptar el mensaje

Estyo viendo el tema de encriptacion con el algoritmo de RSA, ¿estás diciendo que debo encriptar la contraseña y usuario con ese algoritmo RSA en Javascript?

[Profesor_Falken]

Buenas,

Si tu unico problema es el usuario y contrasena y no necesitas encriptar toda la comunicacion, entonces puedes utilizar simplemente un algoritmo de encriptacion de clave simetrica como AES256.

Puedes encriptar facilmente en javascript con esta libreria:
https://code.google.com/p/crypto-js/

Posteriormente desde java desencriptas usando JCE:
http://javapapers.com/java/java-symm...ion-using-jce/


Un saludo

[Tusade]

Iniciado por Profesor_Falken

Buenas,

Si tu unico problema es el usuario y contrasena y no necesitas encriptar toda la comunicacion, entonces puedes utilizar simplemente un algoritmo de encriptacion de clave simetrica como AES256.

Puedes encriptar facilmente en javascript con esta libreria:
[url]https://code.google.com/p/crypto-js/[/url]

Posteriormente desde java desencriptas usando JCE:
[url]http://javapapers.com/java/java-symmetric-aes-encryption-decryption-using-jce/[/url]


Un saludo

Gracias, ¿pero eso no lo capturarán igual que un md5 o un sha256? Es decir, que si yo capturo la clave, pues hago una petición con esa clave en vez del texto plano y accedo igualmente al servidor.

Perdón si me explico mal, pero es que estoy preocupado por esto:

Normalmente suelen decir que hagas un hash de la contraseña y así esta no viajará en claro por la red. Esto no es una solución porque si yo soy un “hacker” maligno y consigo ver la comunicación, no podré leer la contraseña bob123, pero si que veré 2acba7f51acfd4fd5102ad090fc612ee, que es el resultado de aplicar una función hash (md5) a bob123.

La cosa es que a mí, como atacante, me da lo mismo ver lo primero que lo segundo, ya que sé que si mando la petición de login a la página “web” poniendo como usuario bob y como contraseña 2acba7f51acfd4fd5102ad090fc612ee voy a poder acceder a la aplicación (entiéndase que esto se realizará usando alguna herramienta de manipulación de peticiones HTTP como burp o tamperdata etc…).

[Profesor_Falken]

Gracias, ¿pero eso no lo capturarán igual que un md5 o un sha256?

Tienes toda la razon.

En cualquier cosa MD5 y SHA256 son metodos de encriptacion asimetrica. Es decir, que no de pueden desencriptar. No son lo mismo ni se utilizan para lo mismo que AES.

Necesitas evitar entonces el ManInTheMiddle.

En ese caso necesitas si o si algo que encripte la conexion punto a punto a nivel de protocolo. Es decir, que necesitas SSL o TLS.
Hacer la conexion SSL no cuesta dinero. Lo que cuesta dinero es el certificado, que sirve para que el navegador no te de avisos.

Si quieres evitar tu problema, tendras que pagar o bien asumir el riesgo. Ten en cuenta que el 99% del las paginas web envian el usuario y contrasena sin una conexion ssl (por ejemplo este foro). Realmente es tan critica la informacion de tu sitio?

En cualquier caso hoy en dia puedes conseguir un certificado bastante barato:
https://www.namecheap.com/security/s...alidation.aspx


Un saludo

[Tusade]

Iniciado por Profesor_Falken

Tienes toda la razon.

En cualquier cosa MD5 y SHA256 son metodos de encriptacion asimetrica. Es decir, que no de pueden desencriptar. No son lo mismo ni se utilizan para lo mismo que AES.

Necesitas evitar entonces el ManInTheMiddle.

En ese caso necesitas si o si algo que encripte la conexion punto a punto a nivel de protocolo. Es decir, que necesitas SSL o TLS.
Hacer la conexion SSL no cuesta dinero. Lo que cuesta dinero es el certificado, que sirve para que el navegador no te de avisos.

Si quieres evitar tu problema, tendras que pagar o bien asumir el riesgo. Ten en cuenta que el 99% del las paginas web envian el usuario y contrasena sin una conexion ssl (por ejemplo este foro). Realmente es tan critica la informacion de tu sitio?

En cualquier caso hoy en dia puedes conseguir un certificado bastante barato:
[url]https://www.namecheap.com/security/ssl-certificates/domain-validation.aspx[/url]


Un saludo

Muchas gracias. Me has aclarado mucho el tema y estoy más tranquilo.

Pero entonces, por ejemplo este sitio, ¿no podría alguien capturar la clave y contra de un usuario?

La info a proteger es solo el usuario y la contraseña, así que no, no es tan crítica. Pero hombre... yo imagino que alguna "seguridad mínima" debe haber... ¿no?

[Profesor_Falken]

Buenas,

Si por lo menos consigues que no se vea en claro el usuario y el password ya habras conseguido bastante. Puedes generar y enviar desde el servidor siempre un token para usar como clave con la que encriptarlos y asi el valor encriptado cambiara cada vez. Asi aunque se capture la informacion solo servira para un uso.

Capturar la info de internet no es algo tan trivial. Esta viaja por distintos servidores/redes hasta llegar al destino y en algun punto podria haberse colocado un elemento que tome le informacion. Sin embargo todo esto supone mucho esfuerzo, tiempo, conocimientos, recursos y riesgo.

Salvo que la informacion de tu sitio genere mucho dinero no tendras de que preocuparte... y en este ultimo caso seguro que no tendrias problemas para hacerte con un certificado

Un saludo

[Tusade]

Vale, gracias, es que pensaba que capturar información entre cliente-servidor era algo fácil de hacer.

[Xerelo]

Capturar la información es fácil o difícil dependiendo del acceso que se tenga a los sistemas.

Necesitas evitar entonces el ManInTheMiddle.

En ese caso necesitas si o si algo que encripte la conexion punto a punto a nivel de protocolo. Es decir, que necesitas SSL o TLS.

ManInTheMiddle en una red local.

http://tutorialesgranada.blogspot.co...wireshark.html

[Profesor_Falken]

Capturar la información es fácil o difícil dependiendo del acceso que se tenga a los sistemas.

Efectivamente.

Cualquiera que se conecta e introduce sus claves en un sitio sin HTTPS desde su trabajo/universidad o cualquier sitio publico tiene que saber a lo que se expone

[Tusade]

Aprovecho este hilo para preguntar otra cosa sobre el tema del login y la seguridad.

Cuando estoy en mi página del formulario con Mozilla, hago click derecho -> Inspeccionar este elemento -> Consola. Y me aparece un mensaje en rojo diciéndome que el formulario es inseguro porque me pueden capturar las contraseñas y tal...

Entonces voy a este foro, por ejemplo, y en el inicio de sesión hago lo mismo: click derecho -> Inspeccionar este elemento -> Consola. Y no aparece ningún mensaje en rojo sobre inseguridad.

¿Por qué? Sin ninguno de los 2 sitios tiene SSL...

Edito: acabo de verlo, aparece también el mensaje en rojo en la Consola. Pero estoy seguro de haber visto páginas sin protocolo https, que cuando yo miraba la consola en el tema del formulario, no les aparecía el mensaje rojo sobre la inseguridad.

[Tusade]

Si por lo menos consigues que no se vea en claro el usuario y el password ya habras conseguido bastante.

He seguido tu consejo, y lo he hecho de la siguiente manera: en el registro y en el login, antes de hacer el submit, Javascript hashea la clave con el algoritmo sha-256 y lo guarda en la base de datos.

También tengo un código en el registro de usuarios que encripta desde Javascript en el cliente con el algoritmo AES-128 (dado un SecretKeySpec, un IvParameterSpec, y un String personalizado secreto) y desencripta correctamente luego desde el lado del servidor en Java. Esto último lo hago para enviarle la contraseña en texto plano al correo del usuario (lo haré por gmail, que ya viene con SSL).

¿Estoy cometiendo algún fallo garrafal? ¿O está todo "Ok"? Me refiero al tema de seguridad.

Puedes generar y enviar desde el servidor siempre un token para usar como clave con la que encriptarlos y asi el valor encriptado cambiara cada vez. Asi aunque se capture la informacion solo servira para un uso.

No he entendido esto del "token", ¿te refieres a la cookie JSESSIONID?

[Kritik]

Iniciado por Tusade

Las conexiones SSL cuestan dinero, o eso tengo entendido.

Voy a informarme sobre el tema de las claves para simular una conexión ssl.

Como es eso de que las conexiones SSL cuestan dinero? Eso depende del Servidor que tengamos contratado o sea cual sea el servidor nos van a cobrar las conexiones SSL? Quién las cobra?

Yo pensaba que eso era gratis...

[rhijar]

Acabo de leer el post y se me ocurre una solución que nunca he visto pero creo que funciona cuando menos en teoria.

El detalle es que ocupamos una llave que nadie mas pueda tener o... una que nadie pueda utilizar aunque la tenga.

Como lo primero lo veo muy dificil, por que si te capturan el pasword encriptado pues es todo lo que necesitan para loguearse. Esto no sirve de nada.

Y la segunda opción seria:

1.- Cuando el cliente se conecte al servidor, este (servidor) debera generar una llave basada en la dirección IP que sea solo valida para esta IP y la enviara al cliente.

2.- El cliente encriptara la información y la envia al servidor.

3.- EL servidor verifica que la contraseña encriptada venga de la IP correcta, si no viene de la ip correcta no la aceptara aunque venga correctamente encriptada.

Con esto garantizamos por un lado que el hacker no vea la contraseña y por otro lado que aunque la capture encriptada, no la pueda utilizar por que no viene de la ip correcta.

En teoria debería de funcionar y me imagino que los certificados SSL deben de funcionar de manera parecida.