5 ms·

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 d

by 16s 15y ago

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.

grantg 15y ago
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. ;)
jerrya 15y ago
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.
- 16s 15y ago
  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.
  - kelnos 15y ago
    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.
- tzs 15y ago
  > 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).
  - Johngibb 15y ago
    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_Security_Standard http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu...
CoffeeDregs 15y ago
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.
- jerhinesmith 15y ago
  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?
  - deleted 15y ago
    [deleted]
    - deleted 15y ago
      [deleted]
  - shizcakes 15y ago
    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.
    - jerhinesmith 15y ago
      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). Thanks!
runningdogx 15y ago
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 15y ago
  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/ http://codahale.com/how-to-safely-store-a-password/
  - elithrar 15y ago
danielrhodes 15y ago
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.

by 16s 15y ago

grantg 15y ago

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

jerrya 15y ago

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.

16s 15y ago
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.
- kelnos 15y ago
  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.
tzs 15y ago
> 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).
- Johngibb 15y ago
  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_Security_Standard http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu...

CoffeeDregs 15y ago

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.

jerhinesmith 15y ago
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?
- deleted 15y ago
  [deleted]
  - deleted 15y ago
    [deleted]
- shizcakes 15y ago
  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.
  - jerhinesmith 15y ago
    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). Thanks!

runningdogx 15y ago

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 15y ago
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/ http://codahale.com/how-to-safely-store-a-password/
- elithrar 15y ago

danielrhodes 15y ago

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.