0

I'm using Entity Framework 5 in a standalone WPF client. How do I configure entity framework so that my database password, which is in the connection string, is not in plain text in memory?

Jordan
  • 9,642
  • 10
  • 71
  • 141
  • there is no need for ef based configuration, see: http://stackoverflow.com/questions/8760048/encrypt-connectionstring-in-entity-framework-first-code – MUG4N Feb 22 '13 at 19:37
  • http://msdn.microsoft.com/en-us/library/dtkwfdky(v=vs.100).aspx This page can help you encrypt your config file – Brandon Nicoll Feb 22 '13 at 19:37

1 Answers1

1

There are two main ways to deal with connection string security with databases.

As rightly pointed out by @MUG4N and @BNicoll you can encrypt the connection strings in your app.config (or web.config) which will avoid being able to read the settings easily. However the actual user name and password are still stored on the machine in this case, which means that with a bit of work you can retrieve the plaintext password.

In my opinion a far better solution is to use the account running your application to authenticate directly with SQL. This means the username/password is never used in the auth cycle and instead a NTLM or kerberos token based authentication is used which is far more secure and doesnt require storage of decryptable passwords.

To use this method you will need to make sure that you are on a domain, and grant permission for the user account running the app to access the database. You will then need to replace the username/password in the connection string with Integrated Security=SSPI;

Unfortunatly this method requires that you are running in a windows domain which may not be appropriate in your case.

Check out MS Whitepaper on security in connection strings

undefined
  • 33,537
  • 22
  • 129
  • 198
  • Instead, in a server environment, it requires storage of decryptable auth tokens (unless you have a HSM/sysadmin to do it for you on startup). Not as bad as user-chosen passwords, sure, but approximately equivalent to randomly-chosen passwords. – tc. Feb 22 '13 at 23:06
  • @tc. as i understand it unless you have reversible encryption switched on for the domain there is no way to go from an encrypted user token (which is stored locally) to the original password. Tokens are also machine specific which reduces attack vectors if compromised to just originating from the compromised machine. – undefined Feb 22 '13 at 23:23
  • @tc. CF MS recommendations "To help limit access to your data source, you must secure connection information such as user ID, password, and data source name. In order to avoid exposing user information, we recommend using Windows authentication (sometimes referred to as integrated security) wherever possible. Windows authentication is specified in a connection string by using the Integrated Security or Trusted_Connection keywords, eliminating the need to use a user ID and password. " – undefined Feb 22 '13 at 23:30
  • I didn't say that you could get back to the password; I just don't think it adds much security on the whole over a high-entropy password. An attacker can't use it at a login prompt, but can still launch a network attack (anything "machine-specific" doesn't seem useful unless it's in an HSM). OTOH, this is all a bit moot if you trust automatic login; perhaps the real benefit is that the auth token is less likely to be stored in a backup. – tc. Feb 22 '13 at 23:45