3 ms·

you're thinking of Dropbox's zxcvbn [1] demo [2] [1] https://github.com/dropbox/zxcvbn https://github.com/dropbox/zxcvbn [2] https://dl.dropboxusercontent.com

• 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 ago
    Think about what you've just said. How insecure is sending the password (hopefully over an HTTPS connection!) to a remote server?
    • lstamour 12y ago
      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.)
      • slavak 12y ago
        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.
    • nacs 12y ago
      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.
  • yAnonymous 12y ago
    It's only for the signup page so that really isn't a problem.