4 ms·

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 plain

by gabbo 15y ago

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.

leif 15y ago
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.
citricsquid 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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 15y ago
        "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.

by gabbo 15y ago

leif 15y ago

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.

citricsquid 15y ago

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 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      "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.