
Hackers raid eBay in historic breach, access 145 million records - larrys
http://www.reuters.com/article/2014/05/22/us-ebay-password-idUSBREA4K0B420140522
======
ghshephard
Here is what I get when I try and change my password:

    
    
      Page not available
      Ebay is asking its users to reset their passwords due 
      to the unauthorized access to our corporate information 
      network. This may result in a delay of service due to 
      the high traffic volume. We ask for your patience and 
      that you return to eBay soon.
    

I wouldn't think that "password changes" were really that heavy a function.

Edit - Finally got through. They are not letting you change your password
directly, you either need to respond to an SMS or Email. Probably a (very)
good idea if they are worried that someone has done a bulk theft of passwords.

~~~
fatbat
Actually having difficulty even locating where to change my eBay password!

Also I did not receive ANY emails from eBay regarding this. Not sure if it
meant my account was not affected, or it is just taking a while...

( EDIT: Finally found it,
[http://ocsnext.ebay.com/ocs/sr?st=1&query=How%20do%20I%20cha...](http://ocsnext.ebay.com/ocs/sr?st=1&query=How%20do%20I%20change%20my%20eBay%20password)?
)

------
lena
Is it safe to change my password now? All I read in the article is how much
they are investigating this. How do I know the hackers don't still have access
and are now actively monitoring password changes potentially getting more
info? I am concerned that there is nothing about this on the eBay front page
and that I have not received an email from eBay about this

~~~
jacquesm
I wonder if this means the dutch auction site 'Marktplaats' also had its data
copied. PayPal is apparently in the clear (not that I would ever use them
again), but I do have a Marktplaats account and that's an ebay subsidiary.
(they got bought out after ebay realized they were not going to be able to
out-compete them).

------
guelo
Ok, passwords were encrypted, were they salted? Per-account salts? How was the
salt stored? How about the keys? What was the scheme?

Actually, it seems like all sites with sensitive user data should disclose
full technical details of their password scheme. How could we make that a
reality?

~~~
dchest
You need to know how they store passwords because ... what?

~~~
hackinthebochs
So we can understand the risk of compromise.

~~~
dchest
Could you elaborate on that?

~~~
tombrossman
I think the reason people like to know this detail is so they can gauge how
urgently they need to act and change their password(s).

If the attackers got plaintext data (worst-case) and users re-used logins on
other sites, it's a 'holy shit drop everything and change passwords now'
moment.

If Ebay followed best practices then affected users know they can wait a day
or two and update passwords at a convenient time. Hashing, salting, encrypting
all buy you time to react.

Your other comment is correct though, once a password database is compromised
all those affected must assume it will be cracked and so they must change
passwords. The only variable is how quickly they should act.

~~~
MasterScrat
If used properly, can't the good hashing techniques be "safe", at least if the
salt is not leaked?

~~~
mnw21cam
You're thinking of pepper, not salt.

Salt is a random value that is added to a password before it is hashed, so
that two identical passwords do not hash to the same value. The value is
different for each hashed password, and is stored alongside the hash.

Pepper is a configured value that is the same for all hashed passwords, and is
added to the password (and salt) before it is hashed. It is kept secret, and
effectively turns the hash function into a secret hash function. Its merit can
be argued because if an attacker is able to compromise your hashed password
database, they could possibly have compromised your configuration and
discovered the pepper too. However, it does add an extra hurdle for an
attacker.

------
digitalengineer
"3 months ago"... And "eBay suggest users chanche their password"... Wait,
what? I suggest a policy where important breaches in security are disclosed
within a short timeframe.

~~~
watson
They didn't know about the breach until about two weeks ago [1], though that
doesn't normally excuse that they waited two weeks to go public with the
knowledge.

One reason to hold back this information is if going public would make their
investigation harder OR if going public would increase the security risk (e.g.
if the security hole used wasn't yet fixed and going public meant disclosing
something about how the hackers got access). But according to what had been
made public so far this doesn't seem to be the case.

[1] [http://www.ebayinc.com/in_the_news/story/ebay-inc-ask-
ebay-u...](http://www.ebayinc.com/in_the_news/story/ebay-inc-ask-ebay-users-
change-passwords)

~~~
digitalengineer
Agree. Those should be the only reason not to disclose breaches (to the
public).

------
panarky
New information in this article:

1) The user database wasn't just accessed, but 145 million user records were
stolen.

2) eBay hired FireEye's Mandiant subsidiary to do the forensic work.

------
nly
How many billion $ companies will it take before we finally rid ourselves of
plain-text password authentication (regardless of whether or not it's
performed over TLS, or they're using a 'good' hash function for verification)?

The lack of a usable secure password authentication standards for the web is
the most pressing issue in web security these days. If there's one thing in
the next HTML standard that should be depreciated, it's <input
type="password">

~~~
dchest
There is no usable secure password authentication standard that will protect
from password compromise after password database leak. In fact, if you're
talking about SRP, it's worse in this regard compared to, say, using bcrypt.

~~~
nly
SRP as published in RFC2945 (circa 2000), which uses SHA-1, is worse. The
protocol _and general idea_ is a lot better, and can be adapted to use any
hash function you like. Replacing RSA with EC is also trivial. Half a day and
a room full of cryptographers and browser guys and you could RFC these
changes. Given more time, I have no doubt that they could come up with
something entirely new and web-centric.

We have a standards body responsible for stewarding the web, and a handful of
some very smart and well resourced browser vendors who can solve these
problems. Ultimately these guys have to take this burden eventually, and these
people _write_ web standards... not having a standard yet just isn't an
excuse.

Why aren't they doing so? Is it because they're more interested in pushing
their own platforms and authentication solutions (hint: all 3rd party
authentication is horrific). It's not like Google, to pick one, is shy when it
comes to developing their own protocols. And it's not just protocols... why
don't browsers come with cracklib style hints regarding password strength yet?
Why no builtin password generation to go with the existing password storage?
So many things not being done because it's easier to blame the next company
when their database is compromised than cooperating to solve hard
technological and UI failings.

~~~
dchest
Again, SRP is useless against password database leaks. Even if it's used with
scrypt instead of SHA-1, and ECC instead of RSA, it's no better than scrypt.

There is no standard not because nobody invented it, but because it's
impossible in principle (unless we replace passwords with something else).

~~~
nly
SRP _does_ offer reassurance when databases are compromised. If my browser
supported SRP-EC-Scrypt, and users were guided on password strength by their
browsers UI, then there would be negligible public concern regarding
'encrypted passwords' being leaked, or worry about whether eBay or HN is using
MD5 or leaking HTTP POST requests somewhere.

Not to mention SRP verifiers are public keys. Password derived pubkeys like
those in SRP can be used to securely encrypt other sensitive user data while
still allowing users to decrypt and maintain those records interactively.

A good solution isn't "impossible in principle", we just need a full-stack
solution extending from browser UI all the way to your favourite CRUD webapps
database. Most of that complexity falls to the browser vendors, web
application frameworks and languages would jump all over it once there was a
client-side consensus.

We need to change our trust models. I trust eBay as an organisation to offer
me a service. I don't trust the web stack or their servers.

~~~
dchest
It's true that if your browser and websites supported SRP-EC-Scrypt, you would
know that they stored things "securely". However, this won't solve the problem
of people using weak passwords and people using the same password for
different websites. If you use strong passwords and don't reuse them, you
already know your risks.

As for your second point, I don't understand it. Do you mean, with the help of
SRP, you can store some sensitive data on server, which won't be available to
this server, but will be available to user? What's the use of it? This sounds
strangely similar to this idea:
[https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721](https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721)

 _> We need to change our trust models. I trust eBay as an organisation to
offer me a service. I don't trust the web stack or their servers._

Then passwords don't matter, because you assume that attackers already can do
everything with your eBay account.

~~~
nly
> If you use strong passwords and don't reuse them, you already know your
> risks.

Nobody does this. Geeks who use password management are are an extreme
minority, and solutions like LastPass are crock that solve the same problem by
papering over infrastructural failings and mean users are never completely
free to move.

Anecdotally I believe people typically use a 'good password' for banking etc,
and a handful of lazy passwords. Cryptographically speaking, they're all weak
of course, but imho people are better off with knowing one or two really good
passwords (I used a 12 character mixed case password containing symbols
entirely from QWERTY induced muscle memory) and letting their browser deal
with derivation for different endpoints.

> Do you mean, with the help of SRP, you can store some sensitive data on
> server, which won't be available to this server, but will be available to
> user?

Not SRP specifically. Forget SRP. What I mean is generally that any user
public key (whether it was originally derived from a user secret like a
password or not) can be used by an organisation for online encryption and
authentication and offline decryption, where data can be decrypted by either
the organisation using their private key, or by the user using their password.

~~~
dchest
I agree with you that browsers help can improve security, in general. (Mozilla
tried this with BrowserID/Persona, but failed.)

As for your second point, I still don't understand it :-) It's hard to make
something usable without trusting servers in the current browser environment,
even if browser vendors cooperate.

~~~
nly
> It's hard to make something usable without trusting servers in the current
> browser environment, even if browser vendors cooperate.

That's why the solution needs to be built in to web standards like HTTP 2.x
and HTML, rather than shimmed in to a javascript library. The original HTTP
authentication scheme actually did one thing right, and that was bypassing
HTML and Javascript (where any hope of security and privacy is long dead and
buried) and going straight to the browser UI.

~~~
dchest
Could you give one usage example of such scheme if it was properly
implemented?

~~~
nly
Not specifically, no. Armchair solutionary ;).

------
throwwit
With such a large user database, why isn't tar pitting db requests the
norm?... or at the very least, instituting something as simple as a flag on
dummy record requests?

~~~
thrownaway2424
A flag on dummy record requests? You mean have records that don't correspond
to real accounts, and audit access to them? How would you censor them from
legitimate full traversals of the user database? How would you tar-pit
attackers without throttling such legitimate processes?

~~~
dchest
There's an interesting project called "Honeywords" (one of the authors is Ron
Rivest)
[http://people.csail.mit.edu/rivest/honeywords/](http://people.csail.mit.edu/rivest/honeywords/)

Link to paper:
[http://people.csail.mit.edu/rivest/honeywords/paper.pdf](http://people.csail.mit.edu/rivest/honeywords/paper.pdf)

(see also recent paper "Some Remarks on Honeyword Based Password-Cracking
Detection"
[https://eprint.iacr.org/2014/323.pdf](https://eprint.iacr.org/2014/323.pdf))

------
presty
> Cyberattackers compromised a small number of employee log-in credentials,
> allowing unauthorized access to eBay's corporate network, the company said.
> Working with law enforcement and leading security experts, the company is
> aggressively investigating the matter and applying the best forensics tools
> and practices to protect customers.

Seems like the kind of tactic used by spy cells to target people in certain
places.

------
rhubarbcustard
Just tried to change my password and got:

"White spaces are not allowed in password."

Is there a valid reason to disallow spaces in passwords? I can't think of one.

------
TTPrograms
An idea I had a while back -

Build browser add-ons and a javascript site that performs N hashes of your
master passphrase (high entropy) concatenated to the website domain (google,
ebay, etc.). Set that hashed password to be your password on each website.
Then when you use a computer you enter the master password and it generates
all the domain-specific passwords. If that website is breached only the
specific password is released. Even if someone knows you're using this scheme
you can make it arbitrarily difficult for them to break it and get the master
password by making N arbitrarily large.

This way you could use one master password to procedurally generate all of
your passwords from any computer without relying on cloud/storage while still
keeping them relatively independent. It's sort of weak to rainbow tables, but
you could make N large enough and use a high enough entropy password that this
would be a negligible threat I think.

Thoughts?

~~~
zepolen
Changing the master password will be a problem because you will have to update
every site your have an account on.

~~~
TTPrograms
Yeah, that's kind of annoying. You could probably get autofill working
reasonably decently, but it wouldn't be easy.

------
rdl
Seems easier to just delete my account.

~~~
thrownaway2424
Yep. My ebay account can go to its final resting place, next to my linkedin
account and my yahoo account.

------
jacquesm
Nice intrusion detection system they have there. And being able to exfiltrate
a chunk of data that size without any alarms going off does not bode well. For
all you know there is now a copy of the full db living somewhere else, not
just the userdata but also every trade those users ever made. This would allow
a whole bunch of other trouble to happen given that addresses and other
information were also present in the data taken.

For instance, this could be used to set up a series of targeted raids along
the lines of what some gangs have done in Europe in the last decade.

Knowing who has expendable money, buys fancy art, expensive jewelery, what it
looks like and so on could help a lot during the planning of such an
excursion.

------
robomartin
Just changed it.

I don't understand why eBay (and others) don't offer two-factor
authentication. Of course this wouldn't have prevented the data theft but at
least one can have a reasonable degree of certainty that your individual
account will not be compromised with a simple password.

I also strongly suggest that you change the answer to the one-and-only secret
question to something completely unrelated. For example, if the question is
"What's the name of your high school?" the answer could be "violet and purple
are similar". In other words, make it impossible to socially engineer the
answer to such questions. I wonder if these answers were also stolen.

~~~
watersb
> I don't understand why eBay (and others) don't offer two-factor
> authentication

eBay implements 2-factor auth via a PayPal s/Key hardware token.

[https://www.paypal.com/securitykey](https://www.paypal.com/securitykey)

~~~
robomartin
Doesn't that just protect PayPal? How does it protect from someone social-
engineering their way into your eBay (not paypal) account through, say,
customer service?

------
msderosa
With eBay's response to date, there is very little information that allows
users to better evaluate a service in which they have invested trust.
Questions of trust and safety are natural for people to raise in a variety of
everyday circumstances. For example, when people get on a plane or take
medicine its natural for them to be concerned about the safety. In eBay's
case, eBay is a market place and a financial services company so it's
reasonable to ask for high standards and to question what their security
practices are like.

One would also think that eBay would have a strong interest in developing
trust between themselves and their customers, but there is little evidence of
that recognition. Specifically, the going corporate standard for a major
security breach among eBay's corporate peers is (a) full and (b) immediate
disclosure.

By (a) full, note, that eBay has come our with a very murky statement about
exactly what happened. There is nothing more substantial than "you should
change your password but we don't think there is any danger". Well, was there
general database access? Did attackers had access to production servers? All
of them? Is there any impartial 3rd party audit that stands behind eBays
security statements? Further, as part of a full disclose, it's good procedure
to disclose how passwords were stored if they expect to establish trust. They
have had 2 weeks at least to prepare their statements and they can't do better
than the useless "passwords were encrypted"?. There are really only two
possibilities here: (1) passwords were combined with a random salt and then
hashed or (2) they were morons. And right now given their public statement it
looks like (2).

By (b) immediate, note, its not unreasonable to expect that a certain
percentage of eBay's users use the same username / password for both their
eBay and their PayPal accounts. So for a couple of weeks now eBay has been
aware of a potential financial danger to their customers and they have been
sitting on the problem. Fail.

Security breaches happen to everyone. There is no faulting eBay there. The
fault is with all aspects of their response. They have had a major security
breach and they have not responded with a proportional disclosure. And that
implies that security isn't their largest company problem.

------
khoitran19
Can someone please help me understand why their stock price was not impacted
by this? I observed Target when similar incident happened and nothing seemed
to change.

Is the general market neglecting security exploitations or is the damage too
small for those big companies? I personally think that it's a big hit for the
companies. They will have to spend money to patch it up and also lose trusts
from users.

~~~
iLoch
Turns out most people probably don't give a shit and likely won't change their
passwords now unless they're forced.

------
tonylemesmer
I class any address, date of birth, phone number information about me as
"financial related data" as it is used by my bank to identify me. I wish eBay
would stop trying to play down the seriousness of this breach.

Also, on the BBC news this morning (Thurs AM UK) a journalist seemed to hint
that "passwords may or may not have been encrypted".

------
dawkins
From the comments:

"This really won’t affect anything. Most people these days are use to being
hacked, spied on and violated."

------
KbcdPfA
dump: [http://pastebin.com/vmvjGw3N](http://pastebin.com/vmvjGw3N)

------
dkarapetyan
Amazon is probably next.

~~~
jacquesm
It probably isn't for lack of trying that this has not happened.

------
Krunkzie
Too bad security isn't a concern; only the almighty dollar, right?

Cheap excuses for security only add salt to the wound.

------
nzonbi
Billion dollar startup opportunity: un-hackable, secure databases as a
service.

~~~
Noctem
You mean like when Oracle claimed that its servers were "unbreakable"?

It's a ridiculous claim for anyone to make.

------
adventured
"EBay spokeswoman Amanda Miller told Reuters late on Wednesday that those
passwords were encrypted and that the company had no reason to believe the
hackers had broken the code that scrambled them."

That seems to imply that eBay used a singular encryption key across its
accounts. Surely not?

~~~
panarky
Journalists and PR people don't know the difference between encryption and
hashing.

eBay is steering media reports toward the password story.

Much more important and potentially damaging to eBay's reputation and revenue
is that 145 million user records were stolen.

This could be much more damaging than the Target or Adobe breaches.

~~~
SoftwareMaven
Target had payment info. That trumps this easily.

