Storing passwords that can't be hashed in a server application

Question

I have a .NET server application that must store passwords that can't be hashed because some APIs I use need the passwords in plain text.

These passwords can also be exported and imported as part of the system configuration into another server instance of the application or for backup purposes.

The encrypted data will definitely need to be readable by application instances on other servers besides the one it was exported from.

What is the most secure way to accomplish this without too much hassle for the user and minimum risk of data loss because of a lost/unavailable encryption key?

---

EDIT

I am looking more for details like:

• How/where to store the key
• Generating a unique key for each install and storing it vs an application wide common key

...not on which encryption algorithm to use.

---

EDIT II

I should add that this application will be distributed to customers to run on their own servers. It is a client/server application. The passwords stored are only used by our application to pass into external API methods. We don't use them for anything else.

The main concern is when the system configuration is exported as XML for backup or to move to a different machine. This is where we want to protect them, but also make it as easy and flexiable for the user as possible.

Answer 1

Well if you're just looking for a strong algorithm, you could do much worse than using TripleDES. It might be 32 years old but it's still very strong.

If you want something a little newer, AES (originally Rijndael) is fine too.

You might want to compare the performance of each to see what fits you best.

Answer 2

When it comes to encryption, the key is like a hardware dongle. Protect it with your life.

What server are you using? Most modern RDMBS come with encryption features that will handle encrypting the data for you while at rest, no external keys needed. This would at least protect the data while in the server...

Answer 3

you could have your program pgp encrypt them such that your customers pgp key could decrypt them and so could yours. the passwords would only be in plain text while the programming is using them.

Answer 4

Actually, a good way would be to use the user-input password as a seed/key to generate an on-the-fly stronger password. Lots of servers do that all the time. That gives you several benefits. 1. No hassle to the users. 2. You can save the user passwords as a text file. 3. A machine generated password is way stronger than a password provided by a human. 4. You can generate new password with the same seed which makes your protocol stronger for replay attacks.

Try it out.

Answer 5

After the edit in which you described what you are looking for, following are some more suggestions -

If you proceed with using the User password as a key or seed, the key can be stored in a database or even a CSV file correlating with the users. After thats accomplished, next question would be, whats better - generating a unique key every install or having a universal application key. Actually, having a universal application key is a bad idea for several reasons - 1. If it gets cracked once, all your previous exchanges can be cracked as well. 2. Its prone to replay attack, when an encrypted password can be replayed. 3. You should consciously keep changing this key from time to time.

Thus, on any day, generating a unique key is a much better idea. I think you should look into Diffie-Hellman Key Exchange. I think that will solve most of your problems. The concept of D-H key exchange is that, you use your own user provided key to establish a unique (every transaction) key for communication. The best part about this method is that, the actual key is never revealed and you can generate new passwords every time based on the same old seed/key.

Have a look into it.

Answer 6

We store credit card information using asymmetric public-key encryption. Many servers have the public key which is used to encrypt credit cards on the way in. Only our cc gateway application has the private key for decrypting and processing payments. The private key is installed as a cert on the production server.

Since you are storing passwords, you should probably still have a hash for fast user authentication.

http://en.wikipedia.org/wiki/Public-key_cryptography