"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?
Like panarky, I wouldn't take that on face value.
I'm going to guess that a significant number of people use the same password for Ebay as for Paypal. Someone's got a lot of incentive to generate some hashes tonight..
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.
"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.
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.
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?
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?
> 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.
"Much more hacker resistant" authentication is certainly something you could sell as a service; but it's not cheap and nobody wants to pay for security.
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.
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?
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.
Hey good read - particularly agree with alot of the points you make. eBay's UI and design - whats going on there? Its OK by 2002 standard but i just feel like i'm browsing a Geocities shopping cart.
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?
Make a law. I don't think there are actual laws in place that hold companies liable when stuff like this happens. I don't even think they are required to have regular security audits.
Not sure about the US laws, but in South Africa we have the Protection of Personal Information Act (Popi) and it became law on November 26 2013.
"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."
Same in NL; I'm not sure about the implementation details of the law though. At the very least, all personal data needs to be transmitted over HTTPS; I'm not sure if the law makes demands of back-end storage though. It probably doesn't cover passwords.
Well, I'd like to know what scheme they used too, however this is only because of curiosity and my interest in this topic.
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.
That's not an actionable information. There is no reason not to change password and not use different passwords for different websites even if they use yescrypt* with 2 TB ROM.
If they were someone who used the same password everywhere, then if the password was recoverable, they need to change the password everywhere. Not the brightest password strategy but a valid question.
They still need to change the password everywhere they used it even if eBay used a state-of-the-art password hashing. (Remember that eBay asked users to change passwords?)
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.
>They still need to change the password everywhere they used it even if eBay used a state-of-the-art password hashing
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.
No, good password is infeasible to brute-force (not "decrypt", hashing doesn't encrypt anything; I invite you to research the topic you're talking about) even if you use non-salted SHA-1. Slow password hashing is there to protect weak passwords.
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.
>not "decrypt", hashing doesn't encrypt anything; I invite you to research the topic you're talking about
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.
Imprecise language can be used, but not when two terms mean completely different things.
"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)
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.
Good hashing techniques store "salt" along with password. Salt is not a secret key, it's a public value used to make password hashes unique.
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.
Many breaches in the past revealed that passwords were somehow "hashed" or "encrypted" in ways that made it much easier than necessary for the attacker to obtain the clear text passwords.
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.
I know that different password storage schemes provide different security. I don't see how knowing what particular scheme they used would affect your actions.
If you use a secure password and the scheme the company uses is something like scrypt or bcrypt with high work factors, you can be near-certain that your password won't be cracked by an attacker. The amount of computation is just extraordinary.
That said, you would still probably want to change your password if you're paranoid.
If you are capable of estimating the cost of cracking your password, you're capable of understanding that you should use different passwords on different websites and that you should change your password in event of compromise. In which case, the fact that attackers know your leaked password doesn't change anything.
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?
Which is a confirmation that you cannot properly estimate risk/effort involved; the knowledge of the scheme they used to store passwords is useless for you, or even harmful.
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.
(Shrug) It may be time to discuss legislation regarding secure storage of user information. It seems clear that many companies are not willing to use best practices without being forced.
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.
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
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).
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">
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.
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.
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).
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.
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
> 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.
> 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.
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.
> 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.
They don't even allow pasting into the change password field, making using a password manager much harder. Why on earth do people things that's a good idea??!?
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.
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.
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".
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.
99 comments
[ 2.9 ms ] story [ 180 ms ] thread1) 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.
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.
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...? )
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...
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.
It's a ridiculous claim for anyone to make.
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.
https://www.paypal.com/securitykey
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!
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? - ...
*) https://password-hashing.net/candidates.html
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.
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?"
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.
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.
Cheap excuses for security only add salt to the wound.
"This really won’t affect anything. Most people these days are use to being hacked, spied on and violated."
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.
"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?
Also, on the BBC news this morning (Thurs AM UK) a journalist seemed to hint that "passwords may or may not have been encrypted".
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.