3 ms·
> On window.load, [..], it'll fetch zxcvbn.js, which is [..] 700k (330k gzipped) As a client side solution, that download size seems excessive for a password s
by nacs 12y ago
> On window.load, [..], it'll fetch zxcvbn.js, which is [..] 700k (330k gzipped)
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.
- mjevans 12y agoThink about what you've just said. How insecure is sending the password (hopefully over an HTTPS connection!) to a remote server?
- lstamour 12y agoHow 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.)
- slavak 12y agoRunning 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.
- nacs 12y agoJust 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.
- yAnonymous 12y agoIt's only for the signup page so that really isn't a problem.