Hacker News Reader

Comment by 16s | Hacker News Reader

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.

View on HN

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.

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

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

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?

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

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.

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

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.

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:

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.

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.

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.

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

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.

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

    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.

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!

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.

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.

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

Reply on news.ycombinator.com