Live data from Hacker News

Ebay posts every character a user types into the password box

slashcrypto.org

11–20 of 220 posts

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

#11
post #3

Bad title: it works only while you have the password field focused. Bad content: when you log in or register you send your password to the servers anyway. It's irrelevant, since all connections (as shown in your post) are made with https. One could argue "they are seeing what you write even if you haven't sent it yet", but meh, it's just a damn password field, not a chat field. So bad, bad, bad.

They're embedding the password in a GET request. That'll get logged all over the place.

But GET arguments are not visible to 3rd parties when using https. Anything after the host name is sent encrypted.

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

#12

If someone has broken ebay https they will surely be able to catch the whole password at the end.

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.

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

#13
post #10

If someone has broken ebay https they will surely be able to catch the whole password at the end.

Same as every website where you can login.

what do you mean? normally passwords are not stored in logfiles ...

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

#14
I knew there was a reason I always prefer POSTing data as opposed to GET query params.

It still gives attackers the knowledge that if they can get access to the logfiles, they can see passwords. Then the problem becomes getting access to the logfiles!

Any leak of relevant information about security is of potential value.

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

#15

Earlier quoted context omitted.

They're embedding the password in a GET request. That'll get logged all over the place.

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 many people have access to one or more of those logs (for a org the size of ebay, maybe 10-100 people?).

Sure, it's not as terrible as if it was sent over http, but 'not being as the worst it could possibly be' isn't a very high bar.

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

#16
There 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 on their keyboard).

edit: the best sopution for this is probably to wait a specified amount between requests, rather than doing it with each character.

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

#17
post #3

Bad title: it works only while you have the password field focused. Bad content: when you log in or register you send your password to the servers anyway. It's irrelevant, since all connections (as shown in your post) are made with https. One could argue "they are seeing what you write even if you haven't sent it yet", but meh, it's just a damn password field, not a chat field. So bad, bad, bad.

As I said in the Post, it is not a security vulnerability itself, but I want to point out that it can be very dangerous to put a password in a GET request. And the response of ebay is bad too. But thank you for your constructive comment ;)

If you're on https ebay, sending GETs to https ebay then the GET parameters are not sent in plain text. The owasp article you link to mentions that GETs can be sent in clear when you have a mixed http/https scenario. I think your screenshots are a little misleading, as not all of the headers and information you show are sent in the clear when using TLS. The response of ebay seems OK, this isn't a big issue at all.

EDIT: Sorry for the misunderstanding: as mentioned elsewhere, the problem is not so much the user-agent end, but the hops between where the decryption happens and where the information is used. Why expose the information more than needed there? So I guess ebay's response is a bit lacking. They could make things more secure with relatively little effort.

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

#18
post #3

Bad title: it works only while you have the password field focused. Bad content: when you log in or register you send your password to the servers anyway. It's irrelevant, since all connections (as shown in your post) are made with https. One could argue "they are seeing what you write even if you haven't sent it yet", but meh, it's just a damn password field, not a chat field. So bad, bad, bad.

They're embedding the password in a GET request. That'll get logged all over the place.

[deleted]

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

#19

Earlier quoted context omitted.

They're embedding the password in a GET request. That'll get logged all over the place.

But GET arguments are not visible to 3rd parties when using https. Anything after the host name is sent encrypted.

It's not so much the HTTPS but the logs, the server logs are not necessary designed to store all the users passwords.

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

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

Post reply on HN