Hacker News new | comments | show | ask | jobs | submit login
Newegg stores your password in plaintext (ashercodes.com)
196 points by jerrya on May 24, 2011 | hide | past | web | favorite | 115 comments

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.

Obviously other people didn't downvote this comment, since it is now the top comment, but I did downvote it because I don't think it adds anything to the discussion. We can now add to the list of comment categories in this thread "useless meta complaining". OTOH, the fact that this is the top comment right now kinda proves the point that HN has gone downhill since in the past any meta stuff was immediately obliterated. (And yes, I realize this comment is also useless meta crap, but he started it).

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

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

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.

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.

Ok, I'll bite. Why did you bin the recommendation to use a password generator along with other "baloney" using the adjective "dismissive"? I guess it was directed at my comment about PwdHash. That seems like the only thing that would protect somebody in case Newegg's password database was cracked.

Pak called generator users dismissive, not baloney. "Steps users can take to mitigate the effects of a website's security failure" is arguably off-topic in a discussion about that website's security hole. It can be interpreted as minimizing the unnacceptable failure of the site.

I totally agree with you. I started to come here a little over two years ago (one-ish with an account) and I've noticed the definite slide towards less "hackerish" statements. This site really exposed me to the raw hacker mindset (other than the distant likes of RMS and ESR) and it's becoming less interesting to read all of the comments on any random story.

Why the down votes everyone?

Agree. The HN audience is ill-informed about things like stock market economics (see LinkedIn threads) and more surprisingly, intermediate technical issues.

They're all just overflow idiots from reddit lately; one should not expect much out of them.

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.

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.

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.


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

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.

ISPs providing any kind of authenticated PPP store your password in cleartext, because PPP authentication does not work without storing cleartext passwords.

PAP doesn't require the server to store cleartext passwords.

If a customer calls up wanting to know their password, I would bet that they are configuring a new modem and that's why the need it. If their modem knows the password, why do they need to know it?

Email, ftp access, ssh access. There are lots of other reasons for needing to know a password.

I think elithrar was talking about the layer-2 modem password, not the layer-7 application user credentials.

What makes you think they are different?

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

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.

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

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.

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


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.

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.

Among the many reasons not to try implementing this is the fact that secure public key encryption is randomized.

I'm not sure I follow your statement. How would you recommend that I encrypt a piece of data to store into a database? It needs to be reversible (encryption, not a hash), but does not need to be reversible on the production system (the field just needs to be decrypted before analysis, on different machines at a later time).

You could use public key encryption in a cryptosystem to store rows in a database. The "correct" way to do that would be to use /dev/random to generate a 128 bit AES key, encrypt the data with AES, and encrypt the AES key with RSA. That gets you "reversible on one server but not another".

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.

I'm a little lost, perhaps I'm not explaining my problem too well. I really appreciate your assistance so far, and I'll try not to waste too much more of your time or space in the HN databases.

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

Use GPG to encrypt the SSNs. You'll be fine.

I'm implying that customer-facing systems use secure hashes, and that the company also stores encrypted passwords on a server not exposed to the Internet.

The work could be done on a hardware security module, so the key never leaves the well-guarded environment. That would also make a good gatekeeper for requests for the unencrypted password.

> Passwords that can be decrypted reliably are isomorphic to passwords stored in plaintext.

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.

> your password is only as secure as your confidence in the company's policies and employees' integrity.

Thats always the case. Encrypted password or not. There's nothing stopping them from getting your password the next time you log in.

That's certainly true, although such an act would essentially constitute willful deceit at a company policy level, which is much worse than what I was hinting at. The hypothetical situation I was hinting at was something like an unruly employee being able to circumvent the company's process due to lax enforcement, even if the company's process itself was reasonable.

You and gabbo are right. It's not necessarily the case the password is stored in plaintext. I'll update my post.

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.

> 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

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

There are very strict rules for what can be stored about a credit card. Specifically, I'm pretty sure that no one is allowed to store the card verification number. And even just storing a credit card in the first place is highly regulated.

Here's more about PCI compliance: http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu...

The thing is, we're not "most folks" (as you say). We understand, and it bothers us. However, "most folks" don't care and use the same password "Letmein!" for every website they visit.

The fact that "most folks" don't recognize the poor security isn't very relevant; it's still poor security. And supposing most people do use the same password for most or all websites they visit, that makes it even more important that sites don't store their passwords in cleartext or in a reversible manner.

    That doesn't necessarily mean that the password
    is stored as plain-text.
Sorta, but the difference is probably only one of magnitude. "Dump DB" is larger but not really remarkably different than "Change customer's e-mail addy to my e-mail addy; email password reminder to 'customer' (now my addy); change customer's e-mail addy back". It's still pretty clear-text-y.

How is that different than most systems that do hash your password and then email you a reset link? The process is slightly different, but the results would be the same. Am I missing something?

Yes. That person would then have access to your account on that service, but would not have the password that you used. Since people often use the same passwords across multiple services, that password being exposed would mean that their accounts on multiple services is theoretically exposed.

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.

More importantly, they can only gain access to the service by changing the password, thus giving away the fact that something has happened.

You can always save a hash, change the password, and then restore the hash. Basically, if you have direct access the the DB you can loin to someones account without them knowing or permanently changing the password. Granted, there are some minor issues with salting passwords etc, but protecting an account from someone with long term RW access to a DB and reasonable understanding of the system is next to impossible.

Ah, yes, that makes sense. I was considering the case where the attacker simply wants access to your account on 'compromised system x' -- not where they're simply using 'compromised system x' as a conduit for obtaining your password (in the hopes that it's used elsewhere across the web).


The other issue is that the former can be done without the affected user knowing it. If a attacker resets your password, you're going to know right away when you can't log in.

I would make a bet this is almost certainly not the case as any company that knows they should be encrypting passwords also knows they shouldn't be giving them out plaintext to customer support agents.

A website employee should only be able to reset the password at most if the passwords is properly SALTed or hashed. Storing passwords in plaintext or not hashing them had to be done. It's insecure to just encrypt the password and rather not hash it.

I'm waiting for NewEgg to pull a Gawker now. ;)

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.

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

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.

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

I did not know this. Thank you for pointing it out. In that case, it's probably not in violation of MA law. It does protect against grey areas that may allow malicious activity against you, e.g. billing address, etc, but it would be a hard sell and not worth anyone's time. Though, it's worth pointing out this is exactly why companies do everything possible to avoid storing PII (e.g. credit card info) even if it's to the customer's disadvantage.

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

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.

You probably don't need to do this depending on why you think you might change encryption schemes. If the idea is just to upgrade to a stronger encryption scheme, you can do so by using BOTH going forward.

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.

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

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

Switching encryption schemes is rare. Why not just force a password reset on all users at that time?

Keeping something secret because it is evil does not dilute the evil.

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.

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.

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.

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

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.

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

If newegg can get your plaintext password, chances are an attacker can too. The distinction is pretty slim, to me, though you're right that it's there.

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.

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.

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

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

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.

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.

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


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.

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


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.

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.

Encryption is inadequate because others can still find out what your password was (Insert disgruntled employee or hacker that gets the master decyption key).

Hashing / SALTing is WAAAAAY safer.

If a system can easily decrypt a password, the programmer that made the system (or just someone looking at the source) can easily access your password.

You may as well say that passwords are always encrypted into ASCII code. The difference between encoding and encrypting has only to do with the difficulty of recovering plaintext. If there is no difference, there is no difference.

"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


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.

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

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.

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.

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?

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

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

Perhaps they've leaked your info and you don't know. Hell, perhaps they don't even know.

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.

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.

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.

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.

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

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

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

I blame the French: http://bit.ly/hjxHZQ

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?

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.

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

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

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.

Ok, I see how my comment could have been misread. Here's my clarification:

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.

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.

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.

That's not the point. If you complain about being unsafe in your neighbourhood someone can't just respond with "buy a gun". No, in this case your city council should do their best in changing the situation.

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.

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.

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.

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.

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact