Well it's obvious that someone working at Ebay is collecting these passwords. Either they intend to steal a lot of money, or they intend to create user profiles based on data that would otherwise be encrypted to them, or they could also be trying to break the account encryption on the whole network this way. Collect enough valid passwords and use them to get enough to make a fingerprint that could enable them to read passwords without having access to higher security clearance.
Ebay posts every character a user types into the password box
61–70 of 220 posts
Re: Ebay posts every character a user types into the password box
#62> 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?
This actually just sounds like a really bad implementation. Some front-end dev wasn't sure what's a good timeout to fire the password to the server on, so he or she just put it on keypress. And then he included the email too, so the backend could look up the user and make a custom password blacklist for this specific case (eg: no personal details allowed). I actually don't disagree with doing a POST of a password to…
> Some front-end dev wasn't sure what's a good timeout to fire the password to the server on, so he or she just put it on keypress.
Ebay is not a two bit software startup, it's an eCommerce powerhouse with extensive QA processes.
Re: Ebay posts every character a user types into the password box
#63[deleted]
Re: Ebay posts every character a user types into the password box
#64Earlier quoted context omitted.
Https is often terminated at a relatively early point, eg the load balancer, so that the request can be properly routed. (Eg if you use AWS, it's generally terminated at ELB). That means the request path may be logged by the load-balancer and whatever routers/proxies they're using, as well as in the request logs of the web server itself. It's completely unnecessary to have everyone's passwords be viewable by however…
Are you implying that POST data isn't going to be transmitted in cleartext beyond that point? Because that's incorrect - HTTPS doesn't selectively encrypt - the whole connection is encrypted. If you're worried about GET data being sent in cleartext, POST is no different.
The point is that GET parameters are more likely to be stored in server logs or other application logs where POST body is usually discarded from such logs.
So someone getting access to the logs will have access to a lot of possibly sensitive data, that's all depending on server and application settings, but by default GET are more likely to leave traces than POST.
It's a subtle but valid concern.
Re: Ebay posts every character a user types into the password box
#65Earlier 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.
Is their algorithm so complex that it can't run in a reasonable time using client side javascript? I have trouble thinking of anything that isn't vastly over-engineered and runs slower than the network lag probably is.
Re: Ebay posts every character a user types into the password box
#66Earlier quoted context omitted.
Pinning doesn't work against the "corporate CA" scenario, at least if the user is using Chrome: Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature t…
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.
If they're MITMing they could replace whatever JS you put with something else, by definition.
Re: Ebay posts every character a user types into the password box
#67Earlier quoted context omitted.
But GET arguments are not visible to 3rd parties when using https. Anything after the host name is sent encrypted.
Https is often terminated at a relatively early point, eg the load balancer, so that the request can be properly routed. (Eg if you use AWS, it's generally terminated at ELB). That means the request path may be logged by the load-balancer and whatever routers/proxies they're using, as well as in the request logs of the web server itself. It's completely unnecessary to have everyone's passwords be viewable by however…
Maybe ebay do the right thing and terminate on the final endpoint, and keep their logs appropriately secured. We shouldn't assume the worst without knowledge.
Re: Ebay posts every character a user types into the password box
#68> 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, going back to my main point: I wonder if something about password entry and email address choice serves as an early warning flag.
I'd kinda be surprised, but I could imagine it potentially being useful.
Re: Ebay posts every character a user types into the password box
#69There 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…
Came here to say this. It is feasible to reconstruct passwords from timing information alone. This has been done against e.g. SSH http://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf and TLS https://www.schneier.com/blog/archives/2010/03/side-channel_...
That's a very interesting interpretation of the linked papers.
While timing information may make brute force attacks against the passwords easier, it is not feasible to reconstruct passwords based on the timing information exposed by Ebay.
It is also worth noting that the ability to perform more efficient brute force searches doesn't really matter in the case of Ebay, as it will not make such attacks feasible over the internet.
Re: Ebay posts every character a user types into the password box
#70> This is not a security vulnerability itself because I think they have implemented this for some reason
IMO just because the behavior is by design doesn't mean it's not a vulnerability. That said, this one seems like a grey area. I'd be worried about password information leaking by making TLS attacks easier in this mode.