Mega explica sus problemas de seguridad

Con el lanzamiento de Mega, en Genbeta y en otros sitios como Ars Technica o Forbes analizamos su seguridad, exponiendo algunos fallos que hacían que Mega no fuese tan seguro como parecía. Hoy, Mega ha respondido en su blog a todos los puntos.

Pasaremos por encima las refutaciones que hace de las acusaciones más obvias. Por ejemplo, sobre el hecho de que "si rompen el protocolo SSL, rompen también la seguridad de Mega", se limitan a comentar que es cierto, pero que entonces habría sitios más interesantes que crackear. Una respuesta muy correcta, teniendo en cuenta que la acusación en sí es bastante absurda.

También aclaran el hecho de que si pierdes tu contraseña pierdes tus datos: es correcto y no es para nada una sorpresa. Anuncian sin embargo que pronto darán la posibilidad de cambiar la contraseña y también de recuperar tu cuenta cuando pierdas la contraseña: de esta forma, si tienes alguna clave de cifrado guardada podrás recuperar algunos archivos.

Por último, hablan sobre el problema de que podrían enviar scripts Javascript al usuario que no cifren correctamente los archivos, diciendo lo que ya os comenté en el anterior artículo: que es un problema de confianza y no de seguridad. Ellos mismos dicen que, si no confías en ellos, no entres en su sitio sino que uses las aplicaciones de un tercero en el que sí confíes.

La parte interesante: SSL de 1024 bits, entropía de las claves y comprobación de duplicados

Vamos ahora a lo que es interesante de verdad. Primero, las acusaciones de que el cifrado SSL de 1024 bits que usaba Mega es inseguro. ¿La explicación? El SSL de 1024 bits se utiliza única y exclusivamente para contenido estático (imágenes, scripts, etc). El cliente en sí, mega.co.nz, usa cifrado de 2048 bits. Además, todos los archivos estáticos cargados se verifican por un script cargado desde mega.co.nz, el más seguro.

¿La razón de que esté hecho así? Fácil: tiempo. Cuanto mayor es la clave más segura es la transmisión, pero también necesita más carga de CPU. Usando 1024 bits mantienen un nivel de seguridad aceptable y ahorran tiempo de procesado. ¿El punto malo? Que están usando una función de hash insegura que permitiría a atacantes cambiar el código Javascript (en el supuesto de que se rompa el SSL de 1024 bits y ejecuten un ataque _man-in-the-middle_) sin que la verificación fallase.

Ahora le toca el turno al control de duplicados. Lo primero que hacen es aclarar que todavía no está activado. Después, explican cómo funcionará. La duplicación se hace sobre todo el contenido cifrado, sin separación por bloques. De esta forma, si se suben dos archivos iguales cifrados con la misma clave, se evita subir el duplicado. Sin embargo, el escenario más probable es que un usuario copie un archivo a otra carpeta o se lo envíe a un amigo, caso en el que Mega no copiará el archivo físico.

Sigue pareciéndome algo muy ineficiente. Si el escenario más probable es en el que un usuario copia explícitamente un fichero, es más sencillo tener un método "copia" en la API que cree un nuevo enlace en la carpeta de destino al mismo archivo, sin duplicar el archivo físico en lugar de hacer la verificación cuando el cliente carga de nuevo el archivo en otra ubicación. Incluso aunque usasen un sistema de búsqueda similar a una tabla hash, que es el más eficiente de todos (para los técnicos, un algoritmo de búsqueda O(1)), el tiempo desperdiciado en buscar duplicados en cada subida sería ridículo. Pero vamos, esto ya entra en el terreno de la eficiencia y no de la seguridad.

Por último, vamos al tema de la entropía en la generación de claves. El problema es que se estaba usando la función _random_ de Javascript, muy predecible y que por lo tanto permitiría romper las claves RSA generadas. Su respuesta es breve: permitiremos al usuario añadir toda la entropía de teclado y ratón que quiera _antes_ de generar la clave. Aunque estaría bien tener otras fuentes de aleatoriedad, imagino que un aviso enorme de "mueve tu ratón y pulsa teclas para mejorar tu seguridad" servirá para la mayoría de usuarios.

A modo de "consejo", en el blog de Mega acaban con un enlace a Megacracker, una herramienta que permitía adivinar las contraseñas de Mega con el correo de confirmación, usando un ataque por diccionario/fuerza bruta. ¿Para qué? Para recordar que no hay que usar contraseñas predecibles que sean susceptibles a este tipo de ataques.

Hay que valorar muy positivamente el esfuerzo de Mega para ser transparente y mejorar. Pocos servicios darían una respuesta tan clara en tan poco tiempo. Sin embargo, para ti, para el usuario, Mega sigue siendo tan seguro como puedan ser otros servicios de almacenamiento en la nube. ¿Por qué sigo pensando esto?

Para mí, a grandes rasgos, hay tres niveles de seguridad en este tipo de sitios de almacenamiento. En el nivel más bajo, tendríamos la seguridad nula: archivos sin cifrar. Después, los que guardan archivos cifrados (Dropbox, SkyDrive y Mega caerían aquí), y después, los que guardan los archivos cifrados con una clave que sólo tienes tú y que no transmiten a nadie. El problema del segundo nivel, el más común, es que no puedes confiar en esos servicios. Por mucha seguridad que digan que ofrecen, ellos son los que tienen la clave.

Mega, al igual que Dropbox, SkyDrive y demás, te va a ofrecer seguridad y privacidad suficiente contra atacantes externos que quieran leer tus archivos. Pero no es un nivel más de seguridad. No se puede considerar como más seguro porque tú no tienes la clave.

Más información | Mega