[throwaway64]

You misunderstand the point of password hashing, it is not about preventing people from breaking into the machine containing the hashes, it is about limiting the damage they can do with millions of passwords as a result of doing so. Most people do not bother to change their password from service to service, login to login. So instead of a breech on one system, you potentially have a breech on thousands.

[gizzlon]

Think you misunderstood GP's point: With enough access you can simply wait for the users to log in and steal their password when they do.

[grimoire]

Not if you are doing your login correctly. You shouldn't need to send passwords to a server to login, just hashes of passwords. That's the point. If your server ever needs to see a real password after the account is created or the password is updated, you have introduced a new vector of attack.

Done correctly, login is an exchange of hashes, not encrypted passwords.

[tomp]

How so?

A simple way to do this would be to send a unique, random salt S for every login, and the user would reply with e.g. sha1(password + S). However, to be able to check that the answer is correct, you would need to know the user's password, in plain text, which brings you back to square one.

To securely do this, you would need commutative hashing functions, i.e. hashing functions f(x) and g(x) such that f(g(x)) = g(f(x)). Actually, to be completely safe, you would need to be able to generate a whole (preferably infinite) family of commutative hash functions g(x), a random one for each login. I have no idea if such functions exist, more importantly, if they are known, it's an interesting idea actually.

[gizzlon]

The web is not exactly the state-of-the-art in network security and encryption. What GP is suggesting is common in other scenarios.

Since you can't trust the server in this scenario, you can't implement in in (normal) javascript.