
Ebay posts every character a user types into the password box - slashcrypto
https://slashcrypto.org/2016/06/29/Ebay/
======
0942v8653
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.

~~~
willvarfar
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](http://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf) and

TLS [https://www.schneier.com/blog/archives/2010/03/side-
channel_...](https://www.schneier.com/blog/archives/2010/03/side-
channel_at.html)

~~~
ryanlol
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.

~~~
willvarfar
Attacks only get better.

~~~
tfinniga
Sometimes they stay at exactly the same level forever.

~~~
willvarfar
Its a classic quote from Bruce Schneier. I should have attributed it. I
thought the crowd would get it.

~~~
sp332
While often attributed to Schneier, he attributes it to the NSA
[https://www.schneier.com/blog/archives/2011/08/new_attack_on...](https://www.schneier.com/blog/archives/2011/08/new_attack_on_a_1.html)

------
edibleEnergy
I reproduced it for fun with BugReplay, the site I've been working on for the
past year:
[https://app.bugreplay.com/shared/report/3efa632d-5b51-45f1-a...](https://app.bugreplay.com/shared/report/3efa632d-5b51-45f1-aa0f-8f5503d9c663)
Checks out, password is in the GET param.

~~~
strictnein
Awesome product. Signed up for the beta.

One small idea: Once the network traffic starts flowing, it's difficult to
switch to the Javascript tab because it's constantly flowing off the screen.
Maybe make the tabs fixed in place? Or have a check mark that can make them
fixed or unfixed?

~~~
edibleEnergy
That's a good point, I've noticed that as well. I added that to the TODO list,
I'd love any further feedback if you have any thoughts.

------
supernintendo
Dear eBay,

Sending a request on each keyboard event to determine password strength is not
only a security vulnerability, it's also poor design. APIs should primarily be
used to consume external resources, not stand in for client side
functionality.

If providing an API for password strength is important (i.e. you want to
guarantee the same behavior across clients), think of your business logic as a
resource and not a service. Rather than force the API figure to it out, have
the API deliver the criteria for this behavior (regex strings, bounds of
password length, etc.) and let your clients figure it out. This addresses the
security concern, decouples your client side and server side logic and
improves performance across the board by reducing network requests and
absolving the server of this responsibility.

If you must go with this design, at least move from a `GET` to `POST` like
others are suggesting.

Just my opinion,

Matyi

~~~
gohrt
This is a terrible idea. It would allow a client to ignore the requirements,
and submit an invalid password.

~~~
supernintendo
You have heard of server-side validation, right?

------
snorremd
Sending your password as you type it as a GET request query parameter seems
awfully hazardous. As you point out the password will appear in all manner of
places, such as HTTP server logs. As the username/email is not included an ops
person might not directly know from the GET request alone what user the
password belongs to. It is not difficult to imagine however that they have
enough info to correlate the IP address of the password strength request with
a user.

~~~
einrealist
Maybe they plan to cache the responses! I mean, from a POST to a GET, there is
clearly a trend.

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

~~~
mootothemax
>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.

~~~
laumars
That might be it. They might use it to detect if someone is pasting a password
in vs typing one in. Which might help identify against bots / attackers
stealing someone's ebay account.

Which would explain why Ebay would be secretive. Because the detection is
easily mitigated if attackers become aware of the detection.

------
esnard
Twitter also sends the password + email + name on each keypress once the user
has entered at least 6 characters on it signup page. [0]

    
    
      [0]: https://twitter.com/signup

~~~
sonnyz
Ugh, I had to do this once on the sign up page at a small company I worked for
about 10 years ago. Ever since then, I've been weary about beginning to fill
out any forms unless I really, really want them to have the info. I still
think its messed up to store user data that hasn't been submitted.

~~~
Nagyman
Yeah, there are shady techniques from companies offering cart abandonment
solutions that do exactly that (e.g. VEInteractive). If you type in an email
address and don't submit the form, they'll still send you chaser emails.

I think there are valid reasons to store incomplete form data, but I don't
think it should be used for reasons the customer did not intend (e.g.
receiving emails).

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

~~~
ryanlol
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.

~~~
thinkt4nk
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.

~~~
ryanlol
>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"?

------
jfahrenkrug
"Let us help you make your password more secure by sending it over the wire a
gazillion times."

------
chrisxcross
Google does the same. They regularly send your password to their server to
rate it. A curl-example is provided below.

I think I already noticed that some websites used googles api to do the rating
of passwords on their website but I can't recall where I saw it.

curl
'[https://accounts.google.com/RatePassword'](https://accounts.google.com/RatePassword')
-H 'Content-Type: application/x-www-form-urlencoded' \--data
'Passwd=jbcfaihrwefgbGWETZHGAESjbnajfcw24704%$§&%§!vf&Emailnotme@useless.domain=&FirstName=Hacker&LastName=News'

or another endpoint:

curl
'[https://accounts.google.com/InputValidator?resource=SignUp'](https://accounts.google.com/InputValidator?resource=SignUp')
-H 'Content-Type: application/json' -d
'{"input01":{"Input":"Passwd","Passwd":"GoogleBatteryHorseStaple","PasswdAgain":"GoogleBatteryHorseStaple","FirstName":"Hacker","LastName":"News","GmailAddress":"i-have@none.yet"},"Locale":"en"}'

~~~
gohrt
"Sending your password to the server" \-- obviously required, that's what
passwords are for.

"Sending each character of your password to the server, before you explicitly
agree to submit" is quite another.

------
brown9-2
_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.

~~~
mschuster91
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.

~~~
brown9-2
In this scenario the distinction between GET and POST becomes irrelevant.

~~~
mschuster91
No, it does not, because usually an appliance will have some sort of logging -
which will usually include the URL, which in turn contains the GET parameter.

------
cm3
Why is it that we didn't improve HTTP Digest Auth but let everyone implement
their own mechanism, where the number of those using a challenge response
protocol is not worth a mention? Do we have to wait until 2018 before
[https://tools.ietf.org/id/draft-yusef-httpauth-srp-
scheme-00...](https://tools.ietf.org/id/draft-yusef-httpauth-srp-
scheme-00.html) can be a thing? Not saying SRP is the best option, but
compared to what's implemented on websites right now, it is much better.

EDIT: I probably am missing details, but surely some secure challenge response
protocol must be available for broad implementation in browsers without
concern for patents, right?

~~~
lann
SRP is an "Augmented PAKE" which does not require the server to ever see the
plaintext password. I'm not aware of any others that are claimed to be patent-
free.

~~~
cm3
Avoiding patents of other protocols seems to have been one of the goals, but
then Thomas has patented SRP itself.
[https://www.google.com/patents/US6539479](https://www.google.com/patents/US6539479)
which is set to expire in two years minus 15 days (Jul 14, 1998).

~~~
colejohnson66
Wouldn't that be 2 years and /a month/ minus 15 days? :)

~~~
cm3
You're right.

------
Pxtl
For those who didn't read TFA - it does this for the password strength checker
when creating a new password, _not_ when logging in.

Honestly, I can see the challenge here. A truly robust password strength
checker would use dictionaries, making it too heavy to run on the client, and
for usability reasons you'd want it to check on keypress.

But it would be nice at the very least if they'd send it as POSTs in the body,
not GET parameters.

~~~
jessriedel
Is a dictionary really that heavy? (Honest question.)

~~~
Pxtl
The ones used by security experts are in the GB range.

Obviously you could do more efficient approaches like converting characters to
recognize that P@ssw0rd is just Password, but then you've increased the
algorithmic complexity you're sending to the client. If you want to get super-
fancy, you've got to find word boundaries and whatnot to find that MyP45512345
is really just MyPass12345.

Of course, the simple brute force approach (server-side check if my password
in this 5GB db of passwords?) might be too slow to use for this case anyways.

~~~
colejohnson66
> The ones used by security experts are in the GB range.

Citation? The only multi gigabyte "dictionaries" I've seen are rainbow tables.
I'm genuinely curious why you'd need multiple gigabytes when the
Dictionary.com app a few years ago was no more than 200 megabytes.

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

~~~
developer2
It's less of a concern about an attacker gaining access to the log files, as
it is that passwords should simply not be stored plaintext... _anywhere_. One
doesn't really need to ask "why", it's just good common sense.

~~~
sigkill
I might even go as far as saying that passwords should simply not be stored at
all anywhere.

------
tempVariable
I did some penetration testing on the Snapshat application last year. It was
also very chatty every key-press on the craete/login screens.

------
athenot
I hope they pad the requests with some random data, otherwise they are sending
encrypted requests with very little entropy.

------
marme
They almost certainly do this to detect bots trying to change passwords. If
the bot tries to change passwords for hundreds of accounts at once they will
end up sending thousands of requests to the password checker and be ip banned
and it can silently just reject every password they try to submit to not tip
off the attacker that they have been detected.

It is a terrible way to implement bot detection but with ebay owning paypal
they are on the hook for lost revenue so bot detection probably takes higher
priority than other security due to the actual economic impact of bots who
steal hundreds or thousands of account at a time being so bad for them

------
mdpm
How has no-one here made the observation that the reason for this is due to
true password strength checks, that use existing password distribution data
that is prohibitive in size to send to the browser?

They're not doing the wrong thing, and the risk of side-channel attacks on
this infrequent behaviour (i.e., not authentication) are trivial compared to
the risks of high entropy passwords that are also highly reused, and are thus
vulnerable to trivial brute force attempts.

------
chris_wot
All those people who think that Amazon don't want anyone to work out their
password complexity algorithm... You just generate a script that works out the
minimum number of characters and then submit a password list to the strength
service. Then you'll know all the strongest passwords according to Amazon, and
from here you can hopefully find patterns to construct rules around running
dictionary cracks.

------
iask
After reading the public post and these comments, do you think they (eBay)
will give a better explanation...or better, an explanation...as to why they do
this? Passwords are becoming difficult to maintain, even with a password
manager. They should've, at least, obfuscate it in some way.

------
hyperion2010
One that I use regularly that seems to be missing is 'set <N> <hour/minute>
timer'. Also and amusing request from my father (who uses voice commands far
more than I do): 'is there some way to print all of these out?'

~~~
brokenmachine
I'm guessing you were also reading the post about Google Voice commands before
this one, and got confused.
[https://news.ycombinator.com/item?id=12000264](https://news.ycombinator.com/item?id=12000264)

------
simbalion
I wonder if there is any example of a large corporation taking action after a
flaw is submitted via an online email form? I think those forms are sent to
people who's job it is to disregard their content as much as possible.

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

~~~
cwilkes
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

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

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

~~~
mabbo
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 plaintext.

Will that solve all problems? Oh, hell no. But it at least strengthens the
mitigation against certain attacks or mistakes.

~~~
phs2501
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.

~~~
xigency
Right, but if a hacker releases a password dump for site X, no one has your
password in plaintext, just the log in hash. That said, that solution requires
JavaScript.

~~~
kstrauser
Yes, but then the attacker can ignore your JavaScript and just send the hash
value they got from the dump. If you calculate hash(password) and send that
for comparison to the hashed password stored in the user database, then
hash(password) _is_ your password from then on.

~~~
mabbo
Yes, but they can't then use the dumped passwords on 300 other websites.

------
chflags
So it's not possible to log on without enabling Javascript?

I guess that's one way to coerce the user into enabling Javascript, at least
temporarily.

~~~
Pxtl
This is the change-password form, not the login form.

------
foobar20202
As an attacker this gives me information about how many characters are in
password. Which can be quite useful information.

------
paulddraper
The HN title seems odd. Most websites send all the characters (unless I
suppose backspace is used).

------
fh973
Bot detection?

~~~
allworknoplay
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.

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

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

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

~~~
SEMW
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.

~~~
userbinator
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.

~~~
dudus
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.

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

~~~
pyre
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.

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

~~~
pyre
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.

------
JamesUtah07
It'd be nice if they additionally implemented https everywhere while they're
at it

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

~~~
hughw
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.

------
emeraldd
Today's xkcd is surprisingly relevant:

[http://m.xkcd.com/1700/](http://m.xkcd.com/1700/)

~~~
tempodox
Indeed. Who would use that site any more after this “feature” has been
publicized?

~~~
raldi
About 162 million people.

~~~
xufi
Ouch, that's quite a bit indeed. One reason why I shop at Amazon more often.

~~~
raldi
[https://en.wikipedia.org/wiki/Dancing_pigs#Origins](https://en.wikipedia.org/wiki/Dancing_pigs#Origins)

------
bru
> why the website is sending docents of requests to Ebay’s servers.

"dozens" maybe?

