> 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).
Ebay posts every character a user types into the password box
131–140 of 220 posts
Re: Ebay posts every character a user types into the password box
#132> 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.
Re: Ebay posts every character a user types into the password box
#133how do you know that they didn't disable logs for this url?
Or they send their logs to an analytics firm. The firm says innocently enough "it doesn't look like we are getting all the logs" and then it is turned on.
There's a lot of ways a policy can be circumvented just because people were trying to do their jobs and didn't know better. Also it is highly unlikely that they have another process to confirm that they aren't logging that url
Re: Ebay posts every character a user types into the password box
#134Earlier quoted context omitted.
This only affects a specific form that the user might interact with once a year (and that's being really optimistic), I don't really see it generating enough requests to make TLS attacks easier.
If it increases the attack surface at all, it makes it easier. Being that this site facilitates monetary transactions, I would hope they would be trying to limit their attack surface in any way possible. I think the real point here is that there are more secure solutions. Saying that it's not all that less secure isn't a great argument.
I'd say it's a very good argument, this appears to be a non-issue that doesn't justify the dev time spent on "fixing" it. We don't live in a world with infinite dev resources.
Edit: Since someone appears to disagree, how would you exploit this "bug"?
Re: Ebay posts every character a user types into the password box
#135> 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.
Re: Ebay posts every character a user types into the password box
#136Earlier quoted context omitted.
Thanks for that. I had no idea. I wish there was a way to grab the certificate in Js. Just so you could alert the user that they are MITMed. As it stands I will have to instruct them to check manually.
You could use https://openpgpjs.org/ for example to provide in-browser cryptography between user and server.
I may use openpgpjs down the line for private messages within rooms. I also want to experiment with WebRTC for private messages and maybe offer some opportunistic peer to peer connections but I haven't gotten the far yet.
Re: Ebay posts every character a user types into the password box
#137Earlier quoted context omitted.
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 p…
Re: Ebay posts every character a user types into the password box
#138> there are some reasons behind our current solutions but I wouldn’t be able to give you more details on it. I'd be curious to know if anyone here can come up with a good enough reason for sending out the user's email & their password(-prefix) at every keystroke?
>I'd be curious to know if anyone here can come up with a good enough reason for sending out the user's email & their password(-prefix) at every keystroke? I wonder if it ties into their fraud detection systems somehow. Fraudsters are lazy - so lazy that, for a good long time, you'd see the exact same few recycled photos of counterfeit items being used in item descriptions. No idea if that's changed recently. Anyway,…
But to what end? A valid password is a valid password whether it comes from user that takes 2 minutes to type it in, a password manager, or a bot.
Re: Ebay posts every character a user types into the password box
#139I guess that's one way to coerce the user into enabling Javascript, at least temporarily.