Live data from Hacker News

Ebay posts every character a user types into the password box

slashcrypto.org

131–140 of 220 posts

Re: Ebay posts every character a user types into the password box

#131

> 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).

Isn't the salt not necessarily supposed to be impossible for the attacker to find out though? like isn't it usually like the username, since it needs to be different for each user but not impossible for the server to figure out?

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.

A lot of setups have one machine doing the SSL and then forwarding the requests over HTTP to backend servers which are logging the requests and would include GET parameters in the log file.

Re: Ebay posts every character a user types into the password box

#133
post #57

how do you know that they didn't disable logs for this url?

It is far safer not to do it in the first place. I can easily see a new sys admin coming in and wondering where all the logs are for a url and enabling it.

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

#134
post #71

Earlier 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 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.

I don't know where you got the information that they do not log these requests, but it is a good assumption, not a bad one. It would be atypical not to log every https request.

Re: Ebay posts every character a user types into the password box

#136

Earlier 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've considered it but the overhead on the server side would be too much for the ad-free (ad's = loss of privacy IMO) and non-monetized vision I have. I use diffie-hellman to distribute an encrypted master key to each client that is used initially for the chat. I'm going to tell users not to consider that private (I can certainly man in the middle it from the server as I'm the one who generated the key) but they can use that key to discuss what private key they will use and then enter it manually (my brown dog's name + my birthday with only the first letter of my last name capitalized for example). In that master key I sent earlier there is also a salt to add to the hash of the password they select so even if the key they pick is weak it still might protect them. Everything is wrapped up in AES256 thanks to the Stanford Javascript Crypto Library.

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

#137
post #128

Earlier 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…

If you hash, with or without salt, on the client for changing the password, you'll also need to hash identically when checking it (i.e. for login). In effect, the hash becomes the password; even if the plaintext is never leaked the first-level hash is just as good for access.

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,…

Same thought here. I was imagining that some sort of timing analysis / fingerprinting could possibly be going on.

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.

Post reply on HN