Aunque la política comercial de Mega es impecable y sus ideas son interesantes, su implementación sufre algunos fallos garrafales (de seguridad). Esto arroja alguna duda sobre todo el proceso y la competencia de los que están detrás de el proyecto.
#0 Tu entradilla es "microblogging" sensacionalista.
Llamar "fallos garrafales de seguridad" a utilizar AES en lugar de SHA para crear checksums de contenido en la parte cliente me parece una considerable exageración sensacionalista. El artículo que enlazas no habla de brechas de seguridad por ninguna parte.
#1 Mi entradilla es la traducción directa de uno de los párrafos, y el artículo no se centra precisamente en la utilización de AES en lugar de SHA. (Por cierto, el artículo no cita ni los fallos XSS, ni en el pobre generador de números aleatorios).
Si estás interesado en profundizar en el tema, comentar que no es la única noticia que comenta las vulnerabilidades de diseño de Mega.
#2 Negativo por mentir. La exageración de la entradilla es enteramente obra tuya y no aparece en ningún párrafo del artículo. De hecho el artículo es una reflexión técnica sobre el nivel de seguridad de la solución, ni siquiera llega a la conclusión de que sea insuficiente como te has inventado tú.
Es más, mientes doblemente. La única conclusión del artículo es que la seguridad de los "checksums" mejoraría utilizando SHA261, SHA1 e incluso MD5 en lugar del AES Davies-Meyer utilizado. Exactamente lo que yo decía en #1.
Te has inventado la entradilla sin haber leído el artículo que enlazas, basándote únicamente en tu interpretación del juego de palabras del titular. Apechuga y no mientas tan descaradamente, hombre, que sabemos leer.
#3While Mega’s sales pitch is impressive, and their ideas are interesting, the implementation suffers from fatal flaws. This casts serious doubts over their entire operation and the competence of those behind it.
Lo cual demuestra lo bien que te has leído el artículo. Las únicas aportaciones adicionales (que no necesariamente están en el artículo) que hecho están en mi comentario #2.
#4 Claro que leí ese párrafo, y era lo que más se parecía a tu entradilla sensacionalista, pero sencillamente no se corresponde con la libre interpretación que tú has hecho (¿"fallos garrafales de seguridad"?). Si pretendes traducir, no reinterpretes las palabras inventándote lo que el autor del artículo ha querido decir.
#5 Fatales... garrafales.. Toda traducción está sujeta a un mínimo de interpretación. Si quieres proponer una alternativa mejor a la traducción, te invito a hacerlo y a proponer a un admin cambiar la entradilla. Verás que (de seguridad) está precisamente entre paréntesis para dar contexto a la frase y que sí, es la única parte que se me puede criticar que haya aportado a título personal, y que a pesar de ello tiene sentido por la decisión de utilizar un algoritmo de hasheo no adecuado que tiene como resultado el PoC que ha publicado el blog.
Comentarios
#0 Tu entradilla es "microblogging" sensacionalista.
Llamar "fallos garrafales de seguridad" a utilizar AES en lugar de SHA para crear checksums de contenido en la parte cliente me parece una considerable exageración sensacionalista. El artículo que enlazas no habla de brechas de seguridad por ninguna parte.
#1 Mi entradilla es la traducción directa de uno de los párrafos, y el artículo no se centra precisamente en la utilización de AES en lugar de SHA. (Por cierto, el artículo no cita ni los fallos XSS, ni en el pobre generador de números aleatorios).
Si estás interesado en profundizar en el tema, comentar que no es la única noticia que comenta las vulnerabilidades de diseño de Mega.
http://www.scmagazine.com.au/News/329640,megacracker-tool-could-reveal-mega-passwords.aspx?utm_source=feed&utm_medium=rss&utm_campaign=SC+Magazine+All+Articles+feed
http://www.lemondeinformatique.fr/actualites/lire-mega-une-securite-deja-compromise-52173.html
Además, lo interesante del asunto es que tanto la clave privada, como (es normal) la pública, la guardan ellos en sus servidores.
#2 Negativo por mentir. La exageración de la entradilla es enteramente obra tuya y no aparece en ningún párrafo del artículo. De hecho el artículo es una reflexión técnica sobre el nivel de seguridad de la solución, ni siquiera llega a la conclusión de que sea insuficiente como te has inventado tú.
Es más, mientes doblemente. La única conclusión del artículo es que la seguridad de los "checksums" mejoraría utilizando SHA261, SHA1 e incluso MD5 en lugar del AES Davies-Meyer utilizado. Exactamente lo que yo decía en #1.
Te has inventado la entradilla sin haber leído el artículo que enlazas, basándote únicamente en tu interpretación del juego de palabras del titular. Apechuga y no mientas tan descaradamente, hombre, que sabemos leer.
#3 While Mega’s sales pitch is impressive, and their ideas are interesting, the implementation suffers from fatal flaws. This casts serious doubts over their entire operation and the competence of those behind it.
Lo cual demuestra lo bien que te has leído el artículo. Las únicas aportaciones adicionales (que no necesariamente están en el artículo) que hecho están en mi comentario #2.
De nada.
#4 Claro que leí ese párrafo, y era lo que más se parecía a tu entradilla sensacionalista, pero sencillamente no se corresponde con la libre interpretación que tú has hecho (¿"fallos garrafales de seguridad"?). Si pretendes traducir, no reinterpretes las palabras inventándote lo que el autor del artículo ha querido decir.
#5 Fatales... garrafales.. Toda traducción está sujeta a un mínimo de interpretación. Si quieres proponer una alternativa mejor a la traducción, te invito a hacerlo y a proponer a un admin cambiar la entradilla. Verás que (de seguridad) está precisamente entre paréntesis para dar contexto a la frase y que sí, es la única parte que se me puede criticar que haya aportado a título personal, y que a pesar de ello tiene sentido por la decisión de utilizar un algoritmo de hasheo no adecuado que tiene como resultado el PoC que ha publicado el blog.