141–150 of 220 posts
Earlier quoted context omitted.
If you hash it you can't determine the "strength" of the password except maybe looking up the hash in a rainbow table.
Do your strength checks in javascript client-side, then hash, then send. Server side can do further checks if it wants on the hashed password (hey, this password was already used, etc).
I reproduced it for fun with BugReplay, the site I've been working on for the past year: https://app.bugreplay.com/shared/report/3efa632d-5b51-45f1-a... Checks out, password is in the GET param.
Honestly, I can see the challenge here. A truly robust password strength checker would use dictionaries, making it too heavy to run on the client, and for usability reasons you'd want it to check on keypress.
But it would be nice at the very least if they'd send it as POSTs in the body, not GET parameters.
I reproduced it for fun with BugReplay, the site I've been working on for the past year: https://app.bugreplay.com/shared/report/3efa632d-5b51-45f1-a... Checks out, password is in the GET param.
Very cool app! I've signed up for the beta; this could be a game changer for my support team.
There is also the possibility of timing attacks on either type of request. By the length you can tell when the HTTPS request is most likely POST /PWDStrength, and from the times that the request is initiated, you can guess at some characteristics of the password (maybe they stopped typing for a second to verify requirements after typing 7 characters; maybe they stopped after 8 because they have to move to the numpad…
Is this another point in the bucket for password managers? Harder to leak any timing related information when a browser plugin auto-fills the form...
So it's not possible to log on without enabling Javascript? I guess that's one way to coerce the user into enabling Javascript, at least temporarily.
For those who didn't read TFA - it does this for the password strength checker when creating a new password, not when logging in. Honestly, I can see the challenge here. A truly robust password strength checker would use dictionaries, making it too heavy to run on the client, and for usability reasons you'd want it to check on keypress. But it would be nice at the very least if they'd send it as POSTs in the body, no…
> Checking the password completely on the server is OK I don't even agree with that, I think the best pratice should be to hash it on the client side before sending it to a server.
Client-side password strength checker would make it functionally impossible to check dictionaries.
For those who didn't read TFA - it does this for the password strength checker when creating a new password, not when logging in. Honestly, I can see the challenge here. A truly robust password strength checker would use dictionaries, making it too heavy to run on the client, and for usability reasons you'd want it to check on keypress. But it would be nice at the very least if they'd send it as POSTs in the body, no…
Is a dictionary really that heavy? (Honest question.)
I reproduced it for fun with BugReplay, the site I've been working on for the past year: https://app.bugreplay.com/shared/report/3efa632d-5b51-45f1-a... Checks out, password is in the GET param.