Newegg stores your password in plaintext
ashercodes.com
ashercodes.com
We have the: completely unverifiable reversible encryption defense, followed by the complaint that reversible is just as bad, followed by every manner of hypothetical baloney. Then we have the dismissive password generator users, followed by the complaint that this is an irrelevant solution. And of course the smattering of people wanting to publicly shame sites that store in plaintext, like more than 0.01% of the Internet will ever care.
tldr, you no longer have to read these comments, screw the karma this will cost me.
What is the ideal we're failing to live up to?
It was said better in another recent comment thread (I forget where): HN comments these days are full of people trying to sound like experts when they have no idea what they are talking about. I post about twice per day, max, and I think that's already more than I deserve to be able to say. Maybe that's what could be enforced here, so that people would really think hard before wasting a comment on hypothetical asides or repeating the same thing ten other people said.
Your perspective reminds me of some people on Stack Overflow who have a particular concept of how everyone else should post. If the people here don't live up to your ideals, maybe you should invite someone who works for Newegg to come comment. Hoping everyone else is going to stay quiet until the commenter of your dreams drops by probably isn't much use.
Granted, it's always alarming to learn when companies either store plain-text or store reversible encrypted passwords where they hold the key, but it's not surprising. Sometimes, usability, convenience and customer experience are more important than IT security, thus mgt decides that these things are acceptable risks.
I'm waiting for NewEgg to pull a Gawker now. ;)
However, stored in plaintext or stored in an encrypted, reversible manner, the password is not stored in what most folks would consider a secure manner.
Mav, the individual I chatted with, was able to quickly get my password. So could other customer service agents. So could any crackers they speak who then know that Newegg is a ripe and juicy target.
I'll respectfully disagree that there is any reason for Newegg or anyone else to keep that password in a reversible manner.
Credit card numbers are stored in a reversible encrypted manner, and that's considered good enough, so one might argue that it is good enough for passwords too since a leaked password is usually not as bad as a leaked credit card number. (I'm not necessarily endorsing that argument--just tossing it out for discussion).
Here's more about PCI compliance: http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu...
That doesn't necessarily mean that the password
is stored as plain-text.
While I don't condone anyone using the same password on multiple services, it happens. Given that hashing a password and providing a reset link is "novice" level easy, it should be a standard practice.
Thanks!
Password hashes are not isomorphic to plaintext passwords, because there can be collisions. That means there is no function to reliably take the stored passwords and turn them back into plaintext passwords; therefore, while reversing some/most passwords through complex iterative functions (e.g. brute force) is possible, the amount of work (particularly for bcrypt, pbkdf2, or other many-round hash+salt schemes) on average is many, many orders of magnitude greater than applying a decryption key. For good passwords, the amount of work is not quite unbounded, but might as well be.
It's true that plaintext passwords and singly-hashed md5 passwords are both quite bad, but at least with the md5 hash nobody can (I think?) currently crack a 32 character random string since there are no rainbow tables for such long passwords. (Assuming the password is vetted for common weaknesses, since "random" alone does not guarantee anything. "aaaaaaaa" is a random 8 char password, after all.) Functions that attempt to reverse non-isomorphic mappings end up being complex and, even in the case of rainbow tables for (unsalted) md5, are much slower than not having to recover the unencrypted password at all, or having some master key that decrypts all passwords.
When we're talking about passwords "vaulted" in non-exposed systems used for customer support, I have a harder time getting upset about it. I don't like systems that work this way, but I see the support/security tradeoff and it's a valid one.
It is likely but not certain that the site in question here did not go through the trouble of setting up a non-exposed secure password vault system for customer support people to use under supervision. Probably they do just store passwords in a column somewhere. But you don't know for sure whether they do.
Nobody needs rainbow tables to crack passwords.
Worth also knowing is that many ISP's store your password using reversible encryption, because if a customer calls up wanting to know their password, it doesn't have to be regenerated. Which can save a lot of time re-configuring modem PPP credentials with your average Joe.
If user passwords are encrypted with symmetric encryption, either the application must have access to the key in order to compare your provided password to the password stored in the DB, or the DB has to have a stored procedure with access to the key.
Therefore it's not -only- customer support that has access, but anyone who hacks the production system also gains access to the key. Of course there are ways to obscure that if it's kept in memory and required as input before the server starts up, but theoretically it's available to anyone who compromises the relevant server.
(And even if there were a system that were implemented as you describe, with access allowed only when a support staffer and a supervisor provides an asymmetric key each, who supervises the supervisors?)
(edit: The offered suggestions show that I wasn't considering non-symmetric or non-software approaches; in any case, at best those seem like complicated band-aids for a situation that should not exist.)
A) Have a traditional hashing scheme independent of the vault
B) Use public-key encryption, and give the production
system only the public key. The server could encrypt
the provided password for decryption by the private key,
and then compare ciphertext. The vault simply has the
private key.
I ask because I am writing an app currently that stores an SSN. The data are downloaded for later use on non-public facing machines, and the SSN needs to be decrypted at that point. I am saving the data using PKI, and will be able to decrypt it later (but anyone without my keys won't be able to).
But you're looking for something beyond that; you want "semi-reversible and deterministic". Determinism is not typically regarded as a feature in cryptosystems. Secure RSA schemes go out of their way to avoid it (read Wikipedia's OAEP article as a starting point).
Generally I think it's a very bad idea to get involved in custom cryptosystems just to store passwords.
If you have a quick link about your first paragraph, that would be appreciated. I'm not sure exactly what that means -- I understand what you mean bygenerate an AES key via /dev/random (gives us nondeterministic key), then encrypt the data with AES. However, why would I use a symmetric encryption system rather than a private/public key pair? With a priv/pub pair, can't I encrypt the data on the server but not be able to decrypt it?
Again, thanks for your help. I'm not actually storing passwords -- those I properly hash. The problem is that my data app has a requirement to collect SSNs (and they need to be reversible, although that can be offline at a later date). Oddly enough, the data requirements only state encryption is required for that -- most of my colleagues are using symmetric encryption with the passphrase stored on the server itself! I was just hoping I could build a system that would be able to encrypt the data, but not decrypt it (the decryption would be handled by another machine not available to the public).
Your application is a much more straightforward application of PKI. You don't need to compare ciphertext, so you could just use GPG. (Please consult someone more expert than me, though. I am not responsible if there's a security problem, etc, etc).
As a secondary reason, public-key encryption is "fast by design", while password hashing techniques are hopefully not. This makes brute-force attacks easier. This actually applies more strongly to SSN's (only a billion possible combinations? Simple!). This can be worked around by adding a properly secured password hash of sufficient length to the plaintext, essentially adding the additional computation of the password hash.
http://crypto.stanford.edu/~dabo/pubs/papers/RSA-survey.pdf
and ask yourself how comfortable you feel about directly using RSA in any context other than encrypting a randomly generated (semantically void) binary encrypting key under secure padding.
Is there a particular attack you're looking at here? I assume it's one based on Coppersmith's theorem, as that section was complicated enough that I'll need a few passes to digest it.
Of course, the plaintext could be voided of any semantics by using still more encryption. The simplest way would be to apply a "public" one-time pad to the plaintext. (edit: Different for each plaintext, of course; otherwise, it's not one-time)
The answer to the question I'm asking myself, of course, is "Not at all." I would use a dual-stacked hash/vault system built on high-level libraries if I were implementing something with these requirements. This involves the least new code, limiting both the time and number of mistakes involved.
I treat that as a different question than the purely-theoretical question of whether such a system could be secure.
This is absolutely correct, and I feel some readers may not exactly understand it. It would be one thing if only you had the key to decrypt the password (as is the case for example when you sync your browser data in Google Chrome). When the same people have access to both your encrypted password and the key to decrypt it, your password is only as secure as your confidence in the company's policies and employees' integrity.
Also, as a side note I should mention that even if Newegg was securely storing your encrypted password and key, they forfeit that when they email it to you in plaintext.
Thats always the case. Encrypted password or not. There's nothing stopping them from getting your password the next time you log in.
From a customer service standpoint, I don't plan to ever let people know I am doing this because they will try to call me out on being evil about it.
For example, if your passwords were stored in MD5 and you wanted to switch to SHA1, you could just make your new hashing scheme the SHA1 hash of an MD5 hash.
This just means the password is easily convertible to plaintext - either because it's stored in plaintext or because it's encrypted and their support folks are able to decrypt it. The former is completely indefensible, the latter is "just" very very bad.
I can think of two situations where design dictates you need passwords to be recoverable, but even though they exist you can (and I do :)) argue the design is wrong:
- Online aggregators like Mint/Yodlee/etc. that pass through your credentials and use screen scraping to get your data. Obviously a faulty design but in the financial aggregator case it's kind of your only choice and many customers are willing to accept the tradeoff.
- I've heard policy enforcement (e.g. "Your current password must not contain any of your N previous passwords and must meet [set of strength criteria]") used as an excuse but I don't really buy it. Not having access to the original password limits your choices for future policy enforcement (to what you could derive from the password when first set) but with a little foresight and extra work you can do fine just with hashes.
Ironically, those policies make you significantly less secure. First, you are storing previous and current passwords in a reversible format. Second, the more difficult your policies, the more likely your users are to treat the password insecurely (PostIt note on the monitor, etc).
Another policy I've seen is "passwords must differ by at least N characters". Again, how many hashes do you need to store for a 16 character password?
For any trivial policy ("don't add numbers to the end", storing the extra hashes will work. All the password policy systems I've seen allow too many axes of freedom for that.
1) In my experience, it's often harder to set your app up to use reversible encryption instead of hashes, especially if you're using an existing authentication library. In a case like this, I would assume the path of least resistance is more likely.
2) Storing passwords as reversible encryption is almost as bad, as the person who compromises your security would likely have access to your application code (and therefore the key to decrypt the passwords), and the negligible benefits of being able to retrieve passwords are not usually worth the potential liability.
So you're saying the support tech gets up from his desk, walks over to the computer with the key, gives the computer some command to produce the key, prints the key or writes it down on a piece of paper, walks back to his computer, types in the key, and finally shreds the piece of paper?
c'mon. really?
no. put my vote in the box marked 'plain text.'
m3mnoch.
I think you're misunderstanding their argument.
m3mnoch.
All you did was talk to a Newegg rep, you said he mis understood you and email you your Newegg password. What evidence do you have and in what logical reasoning does that lead to Newegg storing passwords in plain text?
He could have used your info and looked it up in the Newegg system, probably clicked a check box that says "email password" the system could have decrypted it and sent you the password.
I've seen many sites that actually send you your username and current passwords if you forgot. It doesn't mean that when it's stored on their system it was not encrypted.
Edit: to clarify, my whole point is in reference to how the password is stored in plain text.
Hashing / SALTing is WAAAAAY safer.
Can we make one?
1: https://twitter.com/#!/igrigorik/status/69120340063825920
Whether the password was plain text or decrypted by a tool both are bad practice. The only person who should have any means to make sense of the hash gibberish in any db is the user who created the key.
If they leak my info, then I'll care.
This article strikes down (1) almost by definition.
My passwords are unique - If my newegg password is compromised I supposed people can order some computer parts and ship them to one of my addresses. Pretty sure changing delivery address of stored CC requires card info re-entry like amazon. And I'd just report it stolen and get re-imbursed. BFD.
If the password isn't hashed (ie, 1-way function) and is retrievable by a support rep, then it's ripe for the picking (social engineering is a very well known and effective intrusion tactic).
This is not to say that NewEgg is not to be trusted. I would just assume that whatever password you gave them is potentially already compromised.
Password generators/storage mechanisms like 1Password or KeepassX are very useful here. I just generate a large random password for each site.
Question, under that law, do you need to store plaintext passwords if you hash the passwords on the browser side, since you don't "collect" the actual password from the user, as it never leaves their computer?
Your statement is misleading. That website is essentially creating a hashed password of the original password. But the target website will still consider it your password in which case it will not protect you once the 'password' to the website is known which the author is talking about.
To put it another way, if your password is 'abc' and hashed it becomes: 'ABCDEFG'. The website stores it plaintext as 'ABCDEFG' to which a hacker has it. Then if anyone later accesses the website, they would be able to just type in 'ABCDEFG'.
Pwdhash is just another form of a password manager.
You need take a step back and think about why it is bad that your password is stored in cleartext: if there is a security breach at site X, your login credentials can be tried on many other sites. Since people tend to use the same login/password combo everywhere, your exposure is likely much larger than your info stored at site X.
Which is why vandals/criminals covet password databases.
You seem to be under the misapprehension that the risk is that somebody will search through your email archives (or while it is in transit) and sniff passwords. IMHO, that's a trivial risk.
A tool like Pwdhash will ABSOLUTELY protect you against the "en masse password theft at website" sort of attack, which is the more serious threat.
There are many available solutions that make it easy to have a different, secure password for each site you visit.
Of course, Newegg should adopt a strong hash policy since they've introduced a single point of failure.
"That must mean that Newegg stores your passwords in the clear, as plaintex"
I didn't add the word must there.
I'm not sure I want to just get into rewriting a post, but I did update it to reference the discussion and I did mention the more correct (unlikely) theory that there is a two way encryption involved and everything is hunky-dory.