Is it ok to store passwords that are able to be retrieved?

Question

I'm trying to figure out if it is alright to store passwords that are encrypted using the AES algorithm rather than storing passwords that are salted and hashed with SHA1.

The reason I am wondering this is because my company is in the middle of updating our membership system which is included with our proprietary CMS. Currently, we use AES encryption for passwords. This allows us to easily look up Admin passwords when customers call in for support. When we have staff changes, it is policy to change all admin passwords. The password lookup tool allows us to get the new passwords easily and our work flow isn't interupted.

I get the impression that most people think that hashing salted passwords is the more secure way of handling passwords but I can't figure out a way to comply with current company operations when using hashed passwords. And, the corporate cultural shift required to change our password operations probably won't happen unless I can give them some very compelling reasons to hash passwords.

Is a hashed password generally accepted as required versus an encrypted password? Why?

Answer 1

Encrypting passwords with a reversible encryption is of dubious value.

Obviously the lookup program has access to the key. That means you should assume that anyone who has access to the program also has access to the key. If you are paranoid you should also assume that their spouses, significant others, roomates, etc all have access to that key. Also anyone who has ever broken into the network ever in the past (since key was used) also has access to the key.

The problem with using a system like that is you will never know it is broken. Do I have access to the key? Right now? Can I lookup the password at anytime? As soon as you change it I know what it was changed to?

Using salted hash (vs reversible encyrption) presents its own challenges in implementation but you can be assured that stealing the password list is of little value (if properly implemented with a strong algorithm, multiple rounds, min password standards, and random per record salt). Your current system is "feel good encryption". While it may makes management "feel" safe they aren't actually being safe. It is marginally better than storing passwords in plaintext or on a sticky note it is at best a minimal speed bump to a determined attacker. The largest problem is you can never prove you are "safe" and may not have any warning when you are compromised. You could be compromised right now and not know it.

Answer 2

You mean, inside an application which stores passwords for user authentication.

Normally the motivation for hashing them vs storing encrypted is that it prevents someone who has stolen the database or compromised the server from obtaining the passwords.

If you encrypt them with AES, you're clearly going to have to keep the key somewhere, and can't ever change it (unless of course, you decrypt them all and re-encrypt).

If someone compromises the machine, they can obtain the key, as it is necessarily kept (at least) in memory at some time to decrypt the passwords.

It's either that, or use some fancy PKI. AES is a symmetric cipher.

Encrypting the passwords won't really help the application defend its database against any but the most casual attackers (as an attacker MUST be able to obtain the key). Hashing them makes it difficult for the cleartext to be obtained if passwords are strong.