4

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?

CodesInChaos
  • 11,854
  • 2
  • 40
  • 50
Nzall
  • 7,313
  • 6
  • 29
  • 45
  • why do you need to store the passwords? – mamdouh alramadan Apr 23 '14 at 15:51
  • @mamdouhalramadan Because I need them to authenticate against Dynamics CRM. As I said, The user only needs to enter their password once the first time they start the program. After that, the program needs to authenticate automatically using the saved credentials. I also cannot just use the AD credentials directly, because this also has to work against CRM 2013 Online. – Nzall Apr 24 '14 at 06:43
  • Are you sure this crm doesn't provide SSO functionality! ? – mamdouh alramadan Apr 24 '14 at 12:51
  • SSO functionality? what do you mean by that? – Nzall Apr 24 '14 at 12:52
  • Single sign on. – mamdouh alramadan Apr 24 '14 at 12:53
  • AFAIK, Dynamics CRM supports SSO, but A) only when using an on-premise (so not via online) and B) only through the browser. This also uses credentials saved through Active Directory, but we also may want to use non-AD credentials, such as for the online version. – Nzall Apr 24 '14 at 13:41

2 Answers2

2

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.

mikeazo
  • 2,827
  • 12
  • 29
0

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.

Snox
  • 191
  • 8
  • In this case, database compromise is not really an issue because I'm not really using a database. All I have is a single config file which saves the settings for a single user. I would imagine there are better ways to steal CRM Credentials than individually stealing account data. – Nzall Apr 24 '14 at 10:15
  • Hope this help [Store a password to avoid user interaction](http://security.stackexchange.com/questions/9799/store-a-password-to-avoid-user-interaction?rq=1) – Snox Apr 24 '14 at 10:24
  • I believe I'm already using one of the methods detailed there. The current method I'm using is mentioned as one of the top answers on that question (DPAPI). – Nzall Apr 24 '14 at 13:43