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?
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?
"Yaaay, we're now all safe, right?! No need to change passwords! Right, guys?"
"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."
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.
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.
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.
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.
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)
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.)
Q: Why do you need to know how they store passwords?
A: It's not an issue for them to disclose it.
What you gain by knowing their scheme? What you gain by knowing if it's secure or not?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.