What should I do when I need to store passwords for usage in 3rd party software?

Question

I have a desktop WPF application which authenticates with Dynamics CRM 2011. I ask for the username and password of the user and use them to connect to Dynamics CRM 2011 using CrmConnection.parse("url={2};Username={1};Password{2}",CRMServerUrl, Username,Password). This class then connects to the CRM Server using the provided credentials (authenticated against Active Directory).

The conundrum I'm struggling with is that part of the design of the application is that authentication to CRM is only needed once. Any authentications past the first one should happen automatically using the credentials the user previously entered (And yes, the user can change these in the app if needed). This means I need to store passwords, but I cannot hash them.

Currently, I use the methods suggested by Jon Galloway in Encrypting Passwords in a .NET app.config File. A coworker recommended this. I read some other questions on this matter, but some of the concepts like derived keys, hardware encryption or sending a derived value are either total blind spots to me or are not possible within the design constraints.

What are my options?

Answer 1

After reading your question, but before reading the Jon Galloway post, my initial reaction was to use DPAPI. So I was encouraged when I finally took a look at Jon's post.

Here is why. As Snox says, encrypting the password with a master key makes sense. That is exactly what DPAPI does. But, the master key for DPAPI changes between users and machines. So you don't have to figure out your own way to do this. DPAPI has presumably been studied by cryptographers, so it should be fairly secure.

That said, DPAPI is no silver bullet. It only offers a tradeoff. So it is important to understand the risks involved. First, someone logged in as the same user can decrypt DPAPI blobs by simply calling the right function on the blob. You can lower this threat by using the optional entropy parameter. I'd highly recommend this. That value could be hard-coded into the application or read from a registry key, etc. Hard-coding it into the application might be the way to go as the attacker would have to reverse engineer the app to get the value back (not hard, but definitely raises the bar). Attackers with access to your filesystem can also decrypt DPAPI blobs (assuming they know the optional entropy) using DPAPIck. This also requires knowing the user's password.

Answer 2

One of the reasons stored passwords are usually hashed its because it is a non reversible operation, this means even if the DB gets hacked, the only thing the attacker will know is the hash of the passwords and not the real passwords.

Not being able to do this, you can always encrypt every password you store, using a Master Key, just keep in mind that this is a reversible operation so you will be vulnerable to Ciphertext-only attack (attack model for cryptanalysis where the attacker is assumed to have access only to a set of ciphertexts) and your Key will also be a point of interest so you need to keep it safe.