Today's xkcd is surprisingly relevant: http://m.xkcd.com/1700/
Indeed. Who would use that site any more after this “feature” has been publicized?
About 162 million people.
Ebay posts every character a user types into the password box
121–130 of 220 posts
Re: Ebay posts every character a user types into the password box
#122Earlier quoted context omitted.
You can use a client check to check for the basic requirements, like minimum and maximum length, characters required or allowed etc. Then when the user submits his password, you can do a serverside check.
The reason for using a server-side solution is for a password strength indicator. You need the full algorithm to run against the current entry, and every user-friendly implementation does this on every character input so you know when what you have typed is "strong enough". I'm not particularly a fan of password strength indicators in general, but if you're going to do it at least do it cleanly.
Yes, but why do it on the server and not on the client?
Re: Ebay posts every character a user types into the password box
#123Why is it that we didn't improve HTTP Digest Auth but let everyone implement their own mechanism, where the number of those using a challenge response protocol is not worth a mention? Do we have to wait until 2018 before https://tools.ietf.org/id/draft-yusef-httpauth-srp-scheme-00... can be a thing? Not saying SRP is the best option, but compared to what's implemented on websites right now, it is much better.
EDIT: I probably am missing details, but surely some secure challenge response protocol must be available for broad implementation in browsers without concern for patents, right?
Re: Ebay posts every character a user types into the password box
#124> 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.
This is not really ideal either, because the hash becomes the password. If an attacker got the hashes from your DB, he would only need to send the stolen hash to the server to authenticate.
The ideal way to deal with passwords would be something like SCRAM [1], but you are adding a bunch of complexity on the client side, and you'd need to trust your JS libraries.
[1] https://en.wikipedia.org/wiki/Salted_Challenge_Response_Auth...
Re: Ebay posts every character a user types into the password box
#125I did some penetration testing on the Snapshat application last year. It was also very chatty every key-press on the craete/login screens.
Re: Ebay posts every character a user types into the password box
#126Twitter also sends the password + email + name on each keypress once the user has entered at least 6 characters on it signup page. [0] [0]: https://twitter.com/signup
Ugh, I had to do this once on the sign up page at a small company I worked for about 10 years ago. Ever since then, I've been weary about beginning to fill out any forms unless I really, really want them to have the info. I still think its messed up to store user data that hasn't been submitted.
Re: Ebay posts every character a user types into the password box
#127> 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.
If you hash it you can't determine the "strength" of the password except maybe looking up the hash in a rainbow table.
Re: Ebay posts every character a user types into the password box
#128> 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.
Hashing it on the client side doesn't really have any positive effect on security as the client must then know what salt is used for the hash. This is less secure than just hashing on the server as the salt and number of hash iterations is then unknown by the client (or potential attackers).
I disagree.
Whatever the server receives, it should do all the good things, salted hashing and what-have-you. But no one says what it receives needs to be a plaintext password.
Hash on the client side before sending- unsalted, or salt there as well and pass it along to the server- but let's just ensure that the server never has the ability to see a plaintext password. It can't log it, it can't accidentally leak the plaintext.
Will that solve all problems? Oh, hell no. But it at least strengthens the mitigation against certain attacks or mistakes.
Re: Ebay posts every character a user types into the password box
#129> 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.
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).
Re: Ebay posts every character a user types into the password box
#130> The main point I think is, that GET Requests are logged in log-files which are usually accessible by more people that the main database.
This is an outright assumption, and it's a bad one.
This is a non-issue, because they do NOT log these requests, and it's https.
So move on, this is just noise.