Hackers raid eBay in historic breach, access 145 million records
reuters.com
reuters.com
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.
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.
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...? )
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?
"Popi essentially regulates how anyone who processes personal information must handle, keep and secure that information.
Personal Information broadly means any information relating to an identifiable, living natural person or juristic person (companies, CC’s etc.) and includes, but is not limited to:
contact details: email, telephone, address etc. demographic information: age, sex, race, birth date, ethnicity etc. history: employment, financial, educational, criminal, medical history biometric information: blood type etc. opinions of and about the person private correspondence etc."
are you dense?
Some people seem to need (or even demand by law) to know the scheme, because they see it as a way to assess their security, however they fail to provide a satisfying answer on why exactly they need this knowledge (even when they are told to change passwords!), and how this will change their assessment.
I probably need to structure my questions like 5 Whys (https://en.wikipedia.org/wiki/5_Whys), providing the first few answers myself:
Q. We need to know the exact password hashing/encryption/storage scheme eBay used.
1. Why? - We need to know if the passwords are easily recoverable.
2. Why? - We need to assess our risks.
3. Why? - ...
But even so, the knowledge of password storage scheme in this case is actually harmful! Suppose Alice is reusing passwords, like you said. She learns that eBay used bcrypt, and due to this knowledge thinks her password is safe, and doesn't change her password anywhere apart from eBay. Good? Nope.
I don't see why you keep saying this. These sorts of one-size-fits-all responses to security is why the state of security to day is so bad. A salted hash in itself is useless if you can't decrypt it. If their hashing technique was properly implemented then a good password will be impossible to decrypt. In this scenario there is no reason to change your password.
Personally, the value of an easy to remember password is higher than the miniscule risk of it being decrypted and used for nefarious purposes (which is limited by the fact that nothing of importance is linked to this particular password). I probably won't be changing my ebay password.
In the event compromise like this, you need to change password regardless, because you can't be certain if, for example, attackers had access to server memory (remember that password is kept there before hashing?) or not.
These sorts of one-size-fits-all responses to security is why the state of security to day is so bad.
This sentence is completely false.
You are familiar with a colloquialism, are you not? Imprecise language like this is common among experts in just about every field. You don't not get points for being a pedant when everyone understands what is meant by decrypt in this context.
> because you can't be certain if, for example, attackers had access to server memory
Which is why I asked about the details of the compromise. Getting full access to memory of a system is a few orders of magnitude more difficult than getting admin credentials to a DB.
>This sentence is completely false.
Nope. A decade ago the common security advice was "just MD5 it", and we're still suffering through this boneheaded advice today. Teach concepts, not catchphrases.
"Just MD5 it" advice was not given by knowledgeable security experts. The practice of using a slow cryptographic function to derive password hashes goes back at least to the 1978 paper "Password Security: A Case History" by Robert Morris and Ken Thompson. (I have collected some implementations of historic password hashes (many of which are weak) here: https://github.com/dchest/historic-password-hashes)
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.
Good hashing techniques increase costs for attackers to brute-force passwords.
If they securely encrypted passwords or password hashes, and the key was not leaked, then passwords are safe. However, the probability of attackers stealing the database of passwords and not stealing the encryption key for it is pretty low.
Knowing anything of this still doesn't affect user actions, who should change eBay passwords and never reuse them for anything else.
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.
For example if passwords are only hashed with md5, with no salt, that's basically worthless; md5 is simply too easy to brute force. Same for sha1 (not quite as easy to reverse, but rainbow tables help).
So the mere fact that the passwords were somehow "secured" doesn't mean much by itself.
That said, you would still probably want to change your password if you're paranoid.
The same thing applies to knowing the particular password hash they used: if your password had enough entropy, attackers won't be able to break it even if eBay used "unsalted" SHA-1. But this doesn't change anything, because see previous paragraph.
If, say, your grandfather used the same password for Hotmail and eBay, and he tells you that his password was "bestjetpilot"[1], and asks for your advice on what to do, will you tell him to change both passwords, or just the eBay one? What if he used "y62BYmHoCsjScov6QSOgGCL"? What would you tell him? How would your advice change if you knew the particular password storage scheme eBay used? Do you now need to know which scheme Hotmail uses, because the password is reused on both websites?
[1] http://pages.ebay.com.au/help/account/create-password.html
This doesn't follow. If you estimate that the cost of cracking your password is infeasibly high, there is no reason to change your password.
Q: Why do you need to know how they store passwords?
A: It's not an issue for them to disclose it.
And yes, sorry, I was answering a different question to the one you asked.
1) People asking this question are eBay shareholders who are interested to learn if the company they own will be prosecuted by UK government for storing passwords insecurely; the fact of which was discovered after the leak of 145 million user records.
or
2) People asking this question are potential plaintiffs wanting to know if they should sue eBay for storing their password without hashing it with some hash function defined by law as secure.
Being able to point and laugh is nice too, all seriousness notwithstanding.
(Laughing... yes, but people demanding, by law/at the gun point, to know which password scheme companies use is as far from fun as we can get.)
"Yaaay, we're now all safe, right?! No need to change passwords! Right, guys?"
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...
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.
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">
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.
There is no standard not because nobody invented it, but because it's impossible in principle (unless we replace passwords with something else).
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.
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
> 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.
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.
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.
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.
Link to paper: 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)
Seems like the kind of tactic used by spy cells to target people in certain places.
"White spaces are not allowed in password."
Is there a valid reason to disallow spaces in passwords? I can't think of one.
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?
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.
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.
eBay implements 2-factor auth via a PayPal s/Key hardware token.
http://jacquesmattheij.com/ripe-for-disruption
Ebay has been setting itself up for failure for a long time now, but I'm not surprised that people decided not to take on Goliath. But with this incident there might just be an opportunity to swing the scales in favour of a new entrant.
I'm looking forward to disruption here!
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.
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.
Also, on the BBC news this morning (Thurs AM UK) a journalist seemed to hint that "passwords may or may not have been encrypted".
"This really won’t affect anything. Most people these days are use to being hacked, spied on and violated."
Cheap excuses for security only add salt to the wound.
It's a ridiculous claim for anyone to make.
That seems to imply that eBay used a singular encryption key across its accounts. Surely not?
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.