lunes, diciembre 10, 2007

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)
***************************************************************************************

9 comentarios:

kabracity dijo...

Un tema interesante sin duda, y una de las fuentes de vulnerabilidad en las cuentas de correo.

Recuerdo que hace bastante tiempo, no sé si era terra o yahoo(supongo que terra), que al adivinar la respuesta secreta te mostraba la pass directamente...es decir, la manera perfecta de ser espiado sin que te enteres

Bueno, a ver cómo te curras las siguientes partes del artículo, y a ver si juegas un poco con esas cuentas gratuitas ;)

Anónimo dijo...

Buen post Chema!

Tuve alguna mala experiencia con la dependencia de cuentas...jeje.

Estoy deseando ver las siguientes partes!

Anónimo dijo...

Me gusta la entrada!! y es la ostia de interesante el tema.

Enhorabuena

Anónimo dijo...

Martin Bryan, el jefe saliente del grupo de trabajo WG1 del comité ISO JTC 1/SC 34 encargado de la estandarización de ECMA-376 como ISO 29500 ha escrito un duro informe dirigido al SC34 sobre las presiones que se reciben para certificar el estándar de Microsoft.

http://www.lapastillaroja.net/archives/001440.html


No serán tan buenos en el fondo...

Anónimo dijo...

Pos hablando del test de Turin mirad esto::
Slutbot aces Turing Test*

Chema Alonso dijo...

@lucasfilm,

sí, el artículo original se refiere a ODF por parte de SUN e IBM, PDF por parte de Adobe y OOXML por parte de Spectra y un montón más de casos. No va de las presiones de Spectra. Más bien habla de la presión de conseguir que se cumplan los plazos por parte de los votantes y que parece que no llegan a sacar el trabajo.

Lapastilla roja, escrita por mi amigo debatiente Sergio Montoro, el cual dijo en un debate conmigo "una de las libertades del software libre es que tiene que ser gratis" (lo tengo grabado en video por si alguien no se lo cree) siempre se "pasa un pelín" en las interpretaciones de lo que lee. Yo creo que si abriera un debate en los comentarios de su blog sería más divertido todo.. ¿no?

Saludos!

Chema Alonso dijo...

@dark_tuxvader, ¡Qué grande!

gracias!

penyaskito dijo...

@lucasfilm:
Yo dejé de leer La Pastilla Roja por lo que dice Maligno: demasiado radical y sin posibilidad de debatir, que es la gracia de esta nuestra web 2.0

@Maligno:
Deja de distraer, vamos a lo importante... ¿Habrá tías en pelota en el Reto V (premioooo) que sale el viernes?

Anónimo dijo...

Me alegro que te gustara la noticia, malo que esto llega tarde... el ligue que creía tener en el XXXchat me ha dejado en bancarrota... :-( snif snif snif...

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares