Think about what you've just said. How insecure is sending the password (hopefully over an HTTPS connection!) to a remote server?
How else do you allow someone to use a password to login? I suppose you could run the hash locally if they have JavaScript-- but if they don't, then what? (Edit: Good point, all the hash achieves is that the user's entry isn't sent in clear text -- of course, the hash itself then becomes the password for the purposes of authorization.)
Running a hash locally is equally useless. You've effectively turned the hashed value into the password itself, achieving nothing.
There are secure key-exchange schemes that don't require sending over the raw password, but this isn't an example of one.
Just about every signup and login form does this (and yes preferably over TLS only). What is the problem with it?
The alternative is browser-side encryption of the password before sending but that will get @tptacek rightfully punching you in the face for even mentioning it.
Re:Authentication Cheat Sheet
by yAnonymous on Tuesday February 03, 2015 @04:34AM
(#8989527)
It's only for the signup page so that really isn't a problem.
As a client side solution, that download size seems excessive for a password strength meter.
I understand it contains a dictionary of passwords but that is larger than most JS frameworks. Perhaps a server-based XHR-based solution would be better.