Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ebay posts every character a user types into the password box

slashcrypto.org

Post reply on HN
Print view View original

41–50 of 220 posts

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

#41

Post by userbinator »

SEMW wrote: post #15
CannisterFlux wrote: post #11

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

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.

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

#42

Post by lmm »

mschuster91 wrote: post #32
brown9-2 wrote: post #20

Parameters sent via GET can get cached by proxies and they appear in log-files. Not to argue in favor of sending sensitive data via GET, but I think it is worth pointing out that third-party proxies cannot see the URL or other parts of the HTTP headers or body when the connection is using HTTPS.

Not exactly. In corp/uni environments there may very well be a SSL-stripping proxy - and it works because in a corp setting you have the fake ca cert installed by IT, and in uni you often have to accept a cert when first connecting to the uni VPN.

In that kind of environment all bets are off already and recovering security is hopeless, no?

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

#43

Post by vmateixeira »

wimagguc wrote: post #21

> 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?

Building a user's password dictionary?

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

#44

Post by pyre »

jyounker wrote: post #33
pyre wrote: post #12

Earlier quoted context omitted.

As others are saying, using a GET request embeds that password in the URL, which means that server logs on eBay's side will have your password in them. Server logs aren't always the most protected thing in terms of locking down systems and permission management. On the flip side, most server logs do not have POST/PUT data logged.

Ummm... you're assuming that eBay is using a standard web server configured in some default manner. It's far more likely that this is communication with a custom authentication server of some sort. (Where server means a very large collection of machines.)

It's likely that eBay's internal infrastructure has compensated for this, but it also seems like a potentially overlooked aspect of their system. Even if there are no server logs per se (unlikely), they might be sending request logging information to some sort of analytics server. Since these requests are internal, it's also possible that it's not SSL-protected meaning that people internally could eavesdrop on the requests.

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

#45

Post by allworknoplay »

fh973 wrote: post #27

Bot detection?

Neither bot nor copy/paste detection require this. If you're checking keystroke pace/timing you could simply send a keystroke or clipboard event without the actual contents.

Also, like, if they're sophisticated enough to be doing that, they should probably get the basics right.

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

#46

Post by [deleted] »

drodgers wrote: post #40
cmdrfred wrote: post #34

Earlier quoted context omitted.

I'm writing a Html5/Js end to end encrypted chat app for just this scenario. It won't stop a nation state modifying requests in transit and injecting their own js but it will probably stop a nosy sysadmin.

"It won't stop a nation state modifying requests in transit and injecting their own js" It should stop a nation state if you serve up the JS via HTTPS and use certificate pinning.

[deleted]

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

#47

Post by icebraining »

drodgers wrote: post #40
cmdrfred wrote: post #34

Earlier quoted context omitted.

I'm writing a Html5/Js end to end encrypted chat app for just this scenario. It won't stop a nation state modifying requests in transit and injecting their own js but it will probably stop a nosy sysadmin.

"It won't stop a nation state modifying requests in transit and injecting their own js" It should stop a nation state if you serve up the JS via HTTPS and use certificate pinning.

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 to defeat the protections of key pinning.

https://www.chromium.org/Home/chromium-security/security-faq...

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

#48

Post by cmdrfred »

icebraining wrote: post #47
drodgers wrote: post #40

Earlier quoted context omitted.

"It won't stop a nation state modifying requests in transit and injecting their own js" It should stop a nation state if you serve up the JS via HTTPS and use certificate pinning.

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.

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

#49

Post by arviewer »

brown9-2 wrote: post #20

Parameters sent via GET can get cached by proxies and they appear in log-files. Not to argue in favor of sending sensitive data via GET, but I think it is worth pointing out that third-party proxies cannot see the URL or other parts of the HTTP headers or body when the connection is using HTTPS.

But there is a good chance that these GET parameters are logged by the webserver. Even if these servers are very secure and strictly monitored, one bad employee can cause a lot of trouble.

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

#50

Post by arviewer »

TorKlingberg wrote: post #38
wimagguc wrote: post #21

> 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?

They prefer to implement their password strength measurement server side for some reason. Maybe they don't want to make it public by doing it it JavaScript. Or they want to disallow reusing previous passwords, without leaking them to the client.

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.
Post reply on HN