Storing encrypted passwords

Question

My coworker and I are having a fist-fight civilized discussion over password security. Please help us resolve our differences.

One of us takes the viewpoint that:

• Storing passwords encrypted using a public key in addition to a one-way hashed version is OK and might be useful for integration with other authentication systems in the future in case of a merger or acquisition.
• Only the CEO/CTO would have access to the private key, and it would only be used when necessary. Regular login validation would still occur via the hashed password.
• I have/he has done this before in previous companies and there are many sites out there that do this and have survived security audits from Fortune 500 companies before.
• This is a common, and accepted practice, even for financial institutions, thus there is no need to explicitly state this in the privacy policy.
• Sites like Mint.com do this.

The other one of us takes the following viewpoint:

• Storing passwords, even in encrypted form, is an unnecessary security risk and it's better to avoid exposure to this risk in the first place.
• If the private key falls into the wrong hands, users that use the same password across multiple sites would risk having all of their logins compromised.
• This is a breach of trust of our users, and if this practice is implemented, they should be explicitly informed of this.
• This is not an industry-wide practice and no big name sites (Google, Yahoo, Amazon, etc.) implement this. Mint.com is a special case because they need to authenticate with other sites on your behalf. Additionally, they only store the passwords to your financial institutions, not your password to Mint.com itself.
• This is a red flag in audits.

Thoughts? Comments? Have you worked at an organization that implemented this practice?

Answer 1

The first practice of storing recoverable version of passwords is plain wrong. Regardless of the fact that big sites do this. It is wrong. They are wrong.

I automatically distrust any site that stores my password unhashed. Who knows what would happen if the employees of that big company decide to have fun? There was a case some guy from Yahoo stole and sold user emails. What if someone steals/sells the whole database with my emails and passwords?

There is no need whatsoever for you to know my original password to perform authentication. Even if you decide later to split the system, add a new one or integrate with a third party, you still will be fine with just a hash of the password.

Answer 2

Every time I have anything to do with passwords they are one way hashed, with a changing salt i.e. hash(userId + clearPassword). I am most happy when no one at our company can access passwords in the clear.

Answer 3

I have had to move user accounts between sites (as might happen in a merger or acquisition) when the passwords were one-way hashed and it was not a problem. So I do not understand this argument.

Even if the two applications used different hashing algorithms, there will be a simple way to handle the situation.

Answer 4

I would agree that the safest way remains the one-way hash (but with a salt of course!). I'd only resort to encryption when I'd need to for integrating with other systems.

Even when you have a built system that is going to need integration with other systems, it's best to ask your users for that password before integrating. That way the user feels 'in control' of his own data. The other way around, starting with encrypted passwords while the use is not clear to the end-user, will raise a lot of questions when you start integrating at some point in time.

So I will definitely go with one-way hash, unless there is a clear reason (clear development-wise and clear to the end-user!) that the unencrypted password is immediately needed.

edit: Even when integration with other systems is needed, storing recoverable passwords still isn't the best way. But that of course, depends on the system to integrate with.

Answer 5

• Why should CEOs be more reliable / trustworthy than other people? There are example of high-ranking government people who have lost confidential data.
• There's no reason a regular site has to store a password, not a single one.
• What happens if in the future those private keys can be broken? What if the key used is a weak key, as has happened just recently in Debian.

The bottom line is: Why would one take such great risks for little to no benefit. Most companies aren't ever going to need an encrypted password.

Answer 6

and might be useful for integration with other authentication systems in the future

If there is no immediate need to store the password in a reversable encrypted format, don't.

Answer 7

I'm working in a financial institution and here the deal is: no one should ever know user's password, so the default and implemented policy used everywhere is: one way hashed passwords with a strong hashing algorithm.

I for once stand in favor of this option: you do not want to go into the trouble of handling the situation where you have lost your two-way encryption password or someone stole it and could read the stored passwords.

If somebody loses their password you just change it and give it to them. If a company needs to merge, they HAVE to keep hashed passwords the way they are: security is above everything else.

Think about it this way: would you store your home keys in a box that has a lock with a key you have, or would you better prefer to keep them with you everytime? In the first case: everybody could access your home keys, given the proper key or power to break the box, in the second case to have your keys a potential home-breaker should threaten you or take them from you in some way... same with passwords, if they are hashed on a locked DB it is like nobody has a copy of them, therefore no one can access your data.

Answer 8

Hash Passwords

Storing passwords in a reversible form is unnecessary and risky.

In my opinion, a security breach seems much more likely than the need to merge password tables. Furthermore, the cost of a security breach seems far higher than the cost of implementing a migration strategy. I believe it would be much safer to hash passwords irreversibly.

Migration Strategy

In case of a company merger, the original algorithm used to hash passwords can be noted in a combined password table, and different routines called to verify the passwords of different users, determined by this identifier. If desired, the stored hash (and its identifier) can be updated at this time too, since the user's clear-text password will be available during the login operation. This would allow a gradual migration to a single hash algorithm. Note that passwords should expire after some time anyway, so this would be upper bound on the time migration would require.

Threats

There are a couple of avenues to attack encrypted passwords:

The decryption key custodian could be corrupt. They could decrypt the passwords and steal them. A custodian might do this on his own, or he could be bribed or blackmailed by someone else. An executive without special training is especially susceptible to social engineering too.

An attack can also be made on the public key used for encryption. By substituting the real public key with one of their own, any of the application administrators would be able to collect passwords. And if only the CEO has the real decryption key, this is unlikely to be discovered for a long time.

Mitigation

Supposing this battle is lost, and the passwords are encrypted, rather than hashed, I'd fight on for a couple of concessions:

1. At the very least, the decryption key should require the cooperation of multiple people for recover. A key sharing technique like Shamir's secret sharing algorithm would be useful.
2. Measures to protect the integrity of the encryption key are required too. Storage on a tamper-proof hardware token, or using a password-based MAC may help.

Answer 9

I agree with the guy who thinks it's okay to store a recoverable password.

Wait a minute - no I don't - because it's dumb and wrong*.

_{*see all the other good answers for the details}

Answer 10

The argument in favor of storing them seems to be that it might simplify integration in the case of a merger or acquisition. Every other statement in that side of the argument is no more than a justification: either "this is why it's not so bad" or "other people are doing it".

How much is it worth to be able to do automatic conversions that a client may not want done in event of merger or acquisition? How often do you anticipate mergers and/or acquisitions? Why would it be all that difficult to use the hashed passwords as they are, or to ask your customers to explicitly go along with the changes?

It looks like a very thin reason to me.

On the other side, when you store passwords in recoverable form there's always a danger that they'll get out. If you don't, there isn't; you can't reveal what you don't know. This is a serious risk. The CEO/CTO might be careless or dishonest. There might be a flaw in the encryption. There would certainly be a backup of the private key somewhere, and that could get out.

In short, in order to even consider storing passwords in recoverable form, I'd want a good reason. I don't think potential convenience in implementing a conversion that might or might not be required by a possible business maneuver qualifies.

Or, to put it in a form that software people might understand, YAGNI.

Answer 11

Okay first of all, giving the CEO/CTO access to plaintext passwords is just plain stupid. If you are doing things right, there is no need for this. If a hacker break your site, what's stopping him from attacking the CEO next?

Both methods are wrong.

Comparing the hash of a received password against a stored hash means the user sends his plaintext password on every login, a backdoor in your webapp will obtain this. If the hacker does not have sufficient privileges to plant a backdoor, he will just break the hashes with his 10K GPU botnet. If the hashes cannot be broken, it means they have collisions, which means you have a weak hash, augmenting a blind brute force attack by magnitudes. I am not exaggerating, this happens every day, on sites with millions of users.

Letting users use plaintext passwords to login to your site means letting them user the same password on every site. This is what 99% of all public sites do today, it is a pathetic, malicious, anti-evolutionary practice.

The ideal solution is to use a combination of both SSL client certificates and server certificates. If you do this correctly, it will render the common MITM/Phishing attack impossible; an attack of such could not be used against the credentials OR the session. Furthermore, users are able to store their client certificates on cryptographic hardware such as smart cards, allowing them to login on any computer without the risk of losing their credentials (although they'd still be vulnerable to session hijacking).

You make think I'm being unreasonable, but SSL client certificates were invented for a reason...

Answer 12

i don't want someone able to see my password. i don't care who, or what the reason is.

Answer 13

If you're a fringe case, like mint.com, yes, do it. Mint stores your passwords to several other sites (your bank, credit card, 401k, etc), and when you login to Mint, it goes to all of those other sites, logs in via script as you, and pulls back your updated financial data into one easy-to-see centralized site. Is it tinfoil-hat secure? Probably not. Do I love it? Yes.

If you're not a fringe case, lord no, you shouldn't ever be doing this. I work for a large financial institution, and this is certainly not at all an accepted practice. This would probably get me fired.