MEGA servers store the hash of the password, not the password itself.
Unlocking a key requires a real password but the server knows only the hashed version. This way they can't capture the real password to unlock. The trick would be to make sure server always gets only the hashed password. Even at website login, the password must be hashed before sending!
We used similar crypto for http://timegt.com product where everything is end-to-end encrypted with a keypair generated by the user yet stored at the server. But it's stored at the server in a locked form that can be opened with a password that user entered. But this password is never sent to the server, only the password hash is and is used only to make sure that it's ok to send this locked key to the user. Hopefully this didn't sound too confusing now...
As long as the logins go via normal web page hashing the passwords before sending them does not really add that much security. If the security of the server is somehow compromised, it would be trivial to put up new Javascripts that send the cleartext password to server. Users are not likely to go through the Javascript to check what it is actually doing.
This is how similar services have responded to warrants. They voluntarily alter javascript for some ip addresses in order to capture passwords to use for decryption of the user's files.
It would probably be easy to write your own login page or a browser toolbar that would either do the hashing on a page you control or check that the javascript was what it should be.
At that level of distrust however you might as well encrypt the stuff yourself (and send the decryption keys to the people you want to share with in some other, more annoying but secure, way)
What if I don't trust you? Is it still safe for me to use MEGA?
If you don't trust us, you cannot run any code provided by us, so opening our site
in your browser and entering your password is off limits. If you still want to use
MEGA, you have to do so through a client app that was written by someone you trust.
Fully agreed on the server compromise risk. Fortunately this attack vector would compromise only users who log in after the attack. Users who don't are still safe.
Improving this situation could involve keeping a browser extension that takes care of the hashing algorithm and makes sure the real hash is sent. As long as the extension is not updated, the hashing would be safer.
Unlocking a key requires a real password but the server knows only the hashed version. This way they can't capture the real password to unlock. The trick would be to make sure server always gets only the hashed password. Even at website login, the password must be hashed before sending!
We used similar crypto for http://timegt.com product where everything is end-to-end encrypted with a keypair generated by the user yet stored at the server. But it's stored at the server in a locked form that can be opened with a password that user entered. But this password is never sent to the server, only the password hash is and is used only to make sure that it's ok to send this locked key to the user. Hopefully this didn't sound too confusing now...