Re:Mega was second: The first client-encrypted file sharing ...
by STRML on Sunday January 20, 2013 @01:55PM
(#5087724)
HTTPS is not always the answer, and Securesha.re is not meant to be a direct competitor to Mega. We are focused less on enabling the sharing of movies & applications and more on the sharing of sensitive documents, private information, and so on.
Re:Mega was second: The first client-encrypted file sharing ...
by mentat on Sunday January 20, 2013 @08:43PM
(#5089319)
You really misunderstand the role of HTTPS in the composition of a secure web page, namely securing the components from MITM against any of the active components which could result in a compromise of the entire page rendering. I have zero faith in the security of your solution if you don't or can't understand this.
Re:Mega was second: The first client-encrypted file sharing ...
by exec on Sunday January 20, 2013 @04:32PM
(#5088337)
Not using HTTPS is a critical mistake. Adversary can just do MITM attack and send modified code to the user's browser to steal passwords.
It's not best idea to share sensitive documents without using HTTPS.
Re:Mega was second: The first client-encrypted file sharing ...
by bascule on Sunday January 20, 2013 @10:09PM
(#5089625)
Confirm. This system was obviously designed by people who had no idea what they were doing, which is about the last thing you want in a cryptosystem. Failing to authenticate the JS cryptographic code (TLS would've helped here) makes this system effectively worthless and simple to MitM.
A good read on the matter is Matasano's JavaScript Cryptography Considered Harmful: http://www.matasano.com/articles/javascript-cryptography/
We do not use HTTPS at the moment. As all file transmissions are encrypted, we did not consider it necessary at the moment. A snooper could see the URL of files you have uploaded; however, the password will not be seen.