
Newegg stores your password in plaintext - jerrya
http://ashercodes.com/fyi-newegg-stores-your-password-as-plaintext
======
pak
This comment stream is a great example of HN going downhill. It's literally
ten threads of the same half-informed claims with half-informed stock
counterarguments.

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.

~~~
code_duck
I notice you left out what a 'good' comment stream would consist of.

What is the ideal we're failing to live up to?

~~~
pak
People with direct experience with the elements of the OP (Newegg's security
or lack thereof) voicing their fully-informed opinions. Maybe a Newegg CSR or
security admin. Everybody else is just piling bullshit on top of more
bullshit, because we really don't know anything beyond the alleged experience
of one customer with a blag.

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.

~~~
code_duck
I'd rather read the other comments than musing by some 'old timers' about how
far HN has gone downhill. Not sure whether I need to mention Eternal September
or not.

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.

------
16s
That doesn't necessarily mean that the password is stored as plain-text. The
customer support agent may have simply had the ability to initiate a process
that decrypted it and sent an email notice to the customer.

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.

~~~
runningdogx
Passwords that can be decrypted reliably are isomorphic to passwords stored in
plaintext. That is very undesirable. Even assuming they are encrypted with a
strong key, anyone with access to the decryption key and the database can
trivially recover any password stored by such a system.

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.

~~~
tptacek
When we're talking about passwords stored "encrypted" on customer-exposed
applications, I agree.

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.

<http://codahale.com/how-to-safely-store-a-password/>

~~~
runningdogx
If you're implying that Newegg or any public-facing authentication system
could be implemented with a non-exposed password vault, then I don't see how.

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.)

~~~
amalcon
It could either:

    
    
      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.
    

Neither of these systems are ideal, especially the latter, but they do get
around the one particular issue of a hacked frontend.

~~~
Travis
Why is (B) not ideal? Sounds like you get the usability (recoverable
passwords) without the security issues (assuming that you properly separated
the keys, etc.)

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).

~~~
amalcon
The main reason I was thinking of is that it's very difficult to do public-key
encryption correctly. The normal advice is to just use GPG (or a similarly
battle-tested library). The way these work makes ciphertext comparison
meaningless. That's a good thing for almost all applications, but not for this
one. The alternative is to use code that has not been so thoroughly battle-
tested.

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.

~~~
tptacek
Read this survey paper, particularly the very basic RSA attacks:

<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.

~~~
amalcon
Very interesting skim; I'll have to make a few passes and digest it fully when
I get the chance.

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.

------
bricestacey
Regardless of how they're stored, people should be worried that they're
sending passwords via email. Passwords (especially ones that can cause
financial harm) are considered PII and sending it via email (unencrypted
transmission) is illegal in Massachusetts and probably a few dozen other
states.

~~~
eli
Newegg doesn't save your credit card number. So I guess your newegg password
could lead to financial harm, but only very indirectly.

~~~
pak
Um, what. I most certainly have checked out of Newegg without re-entering my
card number. Even if they store the numbers off premises for PCI certification
reasons, if a Newegg password lets someone log in and buy a hundred flat
screens on my account, that sounds like financial harm to me.

~~~
X-Istence
You need to at least enter your CVV number to make a purchase using a stored
credit card.

------
paulsmith
As a user, I assume the site is not going to do the right thing with my
password. That's why I securely generate a new password for each site using a
master passphrase. Oplop is a good, zero-install tool for doing this.
<http://pauladamsmith.com/blog/2010/12/oplop.html>

------
palehose
I'm developing a site right now in which I capture plaintext passwords on sign
up within a separate table and then offload that data on an hourly basis to
backup so that in case I ever need to change from BCrypt to some other
encryption scheme, I have the plaintext passwords to easily make the switch.
The passwords are never going back into the production db and someone would
need to get physical access to my in house backup server to get these
passwords.

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.

~~~
detst
Why not just authenticate against the existing encryption scheme and then
encrypt into the new scheme on the next log in?

~~~
Johngibb
I second this. Storing plaintext passwords seems like a huge liability,
especially since you just announced it on a public forum ;)

------
gabbo
They obviously don't store a one-way hash if they just regurgitated it to you,
but is this really enough information to conclude the password is _stored_ in
plaintext?

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.

~~~
citricsquid
There is no real difference between plain text and a recoverable encryption.
If a password can be returned to a plain text state it can be considered as
bad as just storing it in plain text.

~~~
gabbo
I almost entirely agree, the difference is minimal (especially if a support
agent can easily recover it, that's a pretty low bar). Encrypting passwords
and keeping the key in an offline (or hardware-protected), highly secure
location helps manage your risk but "don't ever do it" should still be
standard response when considering a system which lets you recover passwords.

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.

~~~
SoftwareMaven
The "n previous" is trivial to do with hashes. The problem is the policies
like "you can't add a number to a previous password". With those, you must
have a reversable password.

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).

~~~
lurker19
Absolutely incorrect. The system stores not only the hash of your password,
but also the hashes of the forbidden variations, at the moment the initial
password is processed.

~~~
SoftwareMaven
"A password can't begin with another password." (meant to capture _password_ ,
_password2_ , _password3_... Are you going to hash every permutation? Seems
like an _awful_ lot of disk space.

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.

------
jarin
It's definitely possible that they're storing the passwords using reversible
encryption. However:

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.

~~~
skidooer
The key doesn't have to be stored on the server. It can be on a private
computer that is not connected to any network at all. Still vulnerable, but
much less so.

~~~
guelo
> It can be on a private computer that is not connected to any network at all.

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?

~~~
skidooer
Unlikely, perhaps. But definitely possible from a technical perspective.

~~~
jarin
Sure, it's also possible that they store the encrypted passwords in a
handwritten ledger and decode them when you log in. I was talking about what
Newegg is most likely doing in real life.

------
uptown
My experiences with Newegg lead me to believe their security policies are
severely lacking and have been for years. Many years ago I sent them an email
asking whether they offered any type of affiliate program. At the time they
didn't ... but instead they sent me a login providing access to many of their
back-end systems. More recently, my credit card number was compromised and
I've narrowed the leak down to Newegg with almost complete certainty. It's not
a site I trust with protecting my information based on those experiences.

------
m3mnoch
really? so you guys think they are rigid enough with security and willing to
do all that extra work in order to two-way encrypt the password (and credit
card data, theoryetically) just so their $8 an hour customer support reps can
decrypt it for you?

c'mon. really?

no. put my vote in the box marked 'plain text.'

m3mnoch.

~~~
jerhinesmith
Nobody said their customer support rep would be the one doing the decrypting.
All it would take is an 'email the user their password' function in the app
that decrypts the password and sends out the email.

I think you're misunderstanding their argument.

~~~
m3mnoch
or, you're thinking the support rep doesn't have the power to change the email
address on the account.

m3mnoch.

------
radioactive21
I still dont get how you concluded that Newegg stores password in plain text.

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.

~~~
yid
If your password is stored in a "decryptable" format, it might as well be
stored in plaintext. Secure systems simply do not have this capability.

------
jackowayed
"is there a public site / wall of shame for web-services that store your auth
info in the clear? we need one."[1]

Can we make one?

1: <https://twitter.com/#!/igrigorik/status/69120340063825920>

~~~
synewaves
<http://plaintextoffenders.com/>

------
entreprenewb
And an fyi, tigerdirect.com does this too. I don't know if it's reversible or
plain text, but I'd still prefer to reset my password on the site rather than
it being sent back to me.

~~~
randlet
hostgator.com does this as well. They even display your password in their
online dashboard.

------
hxf148
As a service (<http://infostripe.com>) we generally only store public
information but we still encrypt most of it to make it less valuable as a
whole in case our db got stolen somehow.

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.

------
pkamb
Whether or not it's stored in "real" plain text is not the issue here. The
real security issue is that they email you your password at all. So anyone who
has access to your inbox, even for 5 minutes while you step out of the room,
now has a way to find your newegg password. And for a significant percentage
of people that will be the one password they use everywhere.

------
sk5t
I wouldn't have a real problem with a password encrypted reversibly via
salted/IV'd RSA public key, with a well-protected, generally offline private
key for recovery in the event of some bizarre necessity. Provided there were
some legitimate reason to reverse it... Still all the other benefits of a one-
way hash, eh?

------
PhrosTT
Newegg has earned my trust - in my book they can do whatever they want.

If they leak my info, then I'll care.

~~~
gabbo
Leak? Your comment only really makes sense if you trust all current and future
Newegg employees to (1) never make mistakes with security impact (2) be
completely incorruptible.

This article strikes down (1) almost by definition.

~~~
PhrosTT
You seem to imply the employees have access to the password as was discussed
above at length. This has not been proven.

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.

------
braindead_in
I use the +tags format for testing email on my website. As a consequence it's
supported completely across the board. It's very useful for testing.

------
learc83
Same for bluehost. They once told me my password over the phone.

------
dreamdu5t
A much bigger issue is the lack of encryption for HTTP logins.

------
SonicSoul
so does Safari books online. in fact they emailed it to me.. in plain text.

------
gzak
I blame the French: <http://bit.ly/hjxHZQ>

~~~
Tyr42
This is terrible.

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?

~~~
lurker19
Unless you have some sort of server-trusted hardware system running on the
client, hashing on the client is equivalent to not hashing at all, since you
cannot force a client to hash before sending a password guess.

------
anonymous246
Don't see a mention of Pwdhash in the comments. That Firfox/Chrome extension
would have protected you. <https://www.pwdhash.com/>

~~~
Joakal
> Don't see a mention of Pwdhash in the comments. That Firfox/Chrome extension
> would have protected you.

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.

~~~
Johngibb
If it incorporates the domain into the hash (which it sounds like it does),
this is still useful. If a hacker gets you password 'abc', they can log into
any other website for which you use the same password. If they get the hash
'ABCDEFG', they only get into that one site.

------
eli
Yeah, that's bad, but it's a bit tough to get worked up about.

There are many available solutions that make it easy to have a different,
secure password for each site you visit.

~~~
jerrya
So I am "worked up" about it, because it's Newegg. If it were Mom & Pop
computer store, I'd probably shrug it off. But Newegg can and should have just
as good a security as an Amazon or Walmart.

------
latch
Stories like this come up every couple months. The true story should be titled
_Jerry Asher doesn't understand basic security_. It's pretty worrisome that
developers don't understand the difference between encryption and hashing, and
then symmetric vs asymmetric key encryption.

Of course, Newegg should adopt a strong hash policy since they've introduced a
single point of failure.

~~~
latch
You're defending your post pretty strongly, and you can downvote me all you
want, but you specifically said

"That must mean that Newegg stores your passwords in the clear, as plaintex"

I didn't add the word _must_ there.

~~~
jerrya
I have not yet achieved or unlocked "downvote". :(

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.

~~~
kelnos
Even if there _is_ 2-way encryption involved, I don't find that an acceptable
means of password storage. If the original password is retrievable by anything
other than painful (hopefully infeasible) brute-force means, it's bad.

~~~
jerrya
I agree. Up above it was pointed out that it's bad because a) people use the
same passwords across sites, and b) by not allowing peeking at a password, bad
employees are forced to use mechanisms that are more likely to create audit
trails, like mechanisms that change a password in the database.

