Correos en la Web (I de IV)

***************************************************************************************
- Correos en la Web (I de IV)
- Correos en la Web (II de IV)
- Correos en la Web (III de IV)
- Correos en la Web (IV de IV)
***************************************************************************************

Ver a los Platero Y Tú en su último concierto juntos en Madrid, en la sala “La Riviera”, fue algo digno del título de su disco. El concierto estaba pensado para que disfrutáramos a muerte, con un final de flipar. Creo que ese concierto me impactó tanto que no me lo podré quitar nunca de la cabeza. Allí andaba Fito despidiéndose, aun con algún pelo aun en la cabeza, a una semana de comenzar la gira de su segundo disco “Los sueños Locos”, en la sala “Aqualung”. De eso quería escribir un rato los próximos días, de lo referente al título del disco de Los Platero y no, como alguien pudiera pensar por el título, de descargarse y ver porno en la web (eso ya lo trataremos más adelante).

Platero y Tú: Correos
Los correos Web son uno de los puntos más importantes de la seguridad de un sistema, no solo por dar acceso al propio servicio de mensajería para el que nacieron, es decir, el intercambio de mensajes electrónicos con ficheritos adjuntos, sino porque son parte de la mayoría de los sistemas de seguridad de las cuentas de otros sistemas.

Es algo normal que una cuenta de casi cualquier sistema o aplicación web, tenga un sistema de recuperación de clave, es decir, el famoso “Me olvidé la contraseña”, por medio de enviarla a una dirección de correo electrónico. Este sistema no está mal, ya que ahorra costes de soporte permitiendo que el propio usuario gestione esta tarea sin que tenga que intervenir el help desk del sistema, pero tiene varias cosas a tener en cuenta.

Durante estos días me gustaría tratar varios aspectos de la seguridad de los mismos, como los mecanismos de recuperar contraseñas, las protecciones contra ataques de fuerza bruta, las preguntas secretas, los recordatorios, los mantenimientos de sesión, herramientas a usar y de algún ataque concreto. Además, para que no os aburráis mucho con la charla, me he estado sacando algunos correos en algunos sistemas gratuitos para que podamos jugar un poco entre nosotros. Así que nada, empecemos a jugar con esto.

Sobre la cuenta asociada

La primera reflexión que se debe tener a la hora de asociar a una cuenta, llamémosla cuenta A, de cualquier sistema (incluyendo las cuentas de correos web), a una cuenta de correo B es que la seguridad de A y la seguridad de B acaban de ser enlazas en dependencia, esto quiere decir que la seguridad de A depende de la seguridad de B. En el famoso y mediático hackeo del servidor de Zone-h los atacantes robaron una sesión de Hotmail mediante un XSS a un usuario editor de la web para después pedir al sistema de Zone-h una recuperación de la password. Este sistema envió un mail a la cuenta asociada con la forma de recuperar la contraseña a la cuenta asociada, es decir, a la de Hotmail. Luego la seguridad del sistema de Zone-h se vio comprometida por la seguridad de la cuenta de correo asociada.

Sobre el almacenamiento de la clave

La segunda reflexión importante que se debe realizar alguien es sobre el almacenamiento de la contraseña en los sistemas de correos. Supongamos que asociamos una cuenta de correo B a una cuenta de cualquier sistema A y pedimos una recuperación de contraseña de la cuenta A por correo electrónico. Si recibo en la cuenta B un correo con la contraseña de la cuenta A o un link a un sitio dónde poder ver la contraseña de la cuenta A entonces la contraseña está mal almacenada en el sistema A pues o se almacena sin cifrar o con un cifrado reversible.

Además, en este caso, nos encontraríamos con una mala situación ya que un atacante podría haber robado la password del sistema de A y el usuario de la cuenta A podría no enterarse nunca. Si se recupera una contraseña, el sistema no debe dar la contraseña original del sistema, debe cambiarla a una nueva contraseña. Si esta es robada por un atacante, el usuario detectaría esta situación cuando intentara acceder y no le funcionara la nueva contraseña.

Sobre la protección contra fuerza bruta de la clave

A medida que aumenta la potencia de cálculo de las maquinas y la velocidad de las conexiones a Intenet se acorta el tiempo que duran los ataques de fuerza bruta. Bruteforcear aplicaciones web cobra cada vez más peso dentro de las auditorías de seguridad. Los correos web deben estar preparados para este tipo de ataques.

Para ello, como primera medida, deben permitir y a ser posible exigir una contraseña compleja con una longitud y complejidad mínima. De nada sirve permitir una contraseña con un alfabeto de 200 caracteres y permitir una longitud de password de 200 si no exigimos que el usuario tenga más de 8 caracteres, por ejemplo, y evitamos que ponga contraseñas del tipo 1234, pepe, password o cualquier otra “evidente”. Si las passwords son cortas los ataques de fuerza bruta las sacan pronto, si las contraseñas son de diccionario las passwords salen en seguida.

Sistemas como Hotmail y Gmail te informan sobre la fortaleza de la password, pero por desgracia esto es algo que no se aplica en la mayoría de aplicaciones y correos web.

Fortaleza de la password según Gmail

Fortaleza de la password según Hotmail
En segundo lugar deben evitar la automatización mediante los bloqueos temporales de intentos, es decir, si alguien se equivoca, no sé, 10 veces, puede ser que se haya olvidado y se acuerde a la vez número 11, a mí personalmente me ha pasado, pero lo más probable es que siendo atacado el sistema. Como buena opción sería el bloquear temporalmente el acceso. En muchos sistemas se empiezan a usar bloqueos progresivos. Si te equivocas 3 veces el acceso se bloquea 3 segundos, si te equivocas 4 veces el sistema se bloquea 5 segundos, si te equivocas 5 veces entonces 10 segundos… Esto hace que los tiempos en los ataques de fuerza bruta se disparen.

Una mala opción es realizar un bloqueo permanente de la cuenta pues un ataque podría ser simplemente dejar sin acceso a alguien al correo (DOS) simplemente con realizar un número X de intentos de acceso.

Otro punto interesante para evitar el bruteforceo de la clave es, aprovechando las interfaces web, complicar la automatización mediante el uso de “human detectors”, es decir, los famosos “captchas”. Sabemos que no son todo lo perfectos que debieran ser, pero son un punto más en la fortificación del sistema.

A todo esto, además, habría que añadir un sistema de alertas, tanto para el usuario, es decir, que le llegue una alerta ante intentos de recuperación de password y del sistema, que le llegue a los administradores alertas ante el intento de bruteforceo de cuentas.

Bueno, basta por hoy. Me abro ... ¡y no de patas!

Saludos Malignos!

***************************************************************************************
- Correos en la Web (I de IV)
- Correos en la Web (II de IV)
- Correos en la Web (III de IV)
- Correos en la Web (IV de IV)
***************************************************************************************