views:

345

answers:

4

Hi, i'm developing a .net winforms desktop application intended to be run at several bank's branches as a backup application whenever the main one (a web application) is unavailable due to connection issues with the bank's central node. The branchs themselves don't count with any enterprise services besides a SQL-Server database. For that reason, the application should be able to connect directly to the SQL-Server. My problem arises when I have to provide the application with a password to connect to the database:

1) Storing the password in clear text in a app.config file or similar is not an option (the customer requires the password to be encrypted)

2) Storing the password encrypted in a configuration file leads to the need of having an encryption key locally available. The encryption key could be just hardcoded in the application's code, but it would be easily readable by using a .net-decompiler or similar.

3) Using a custom algorithm to encrypt/decrypt wouldn't work either due to the same reasons as 2).

4) Integrated security is not supported by the bank

Additionally, the customers requires that they should be able to change the password in one location (within a branch) without the need to go from one computer to another updating config files (that rules out the possibility of using the machine's key to encrypt the password in individual machine's config files like asp.net does)

Would you provide any other approach or suggestion to deal with this problem? I would appreciate any help. Thanks in advance, Bernabé

A: 

You could

  • To use DPAPI to store a encryption/decryption key securely: How To: Use DPAPI to Encrypt and Decrypt Data
  • To install a SQL Server Compact Edition (or another small database) into your workstations and to synchronize data when your web application comes online again.
  • To ask for help inside that institution, as other people could have solved that problem and could to help you.
Rubens Farias
A: 

Definitely agree with the above regarding DPAPI. Microsoft's Enterprise Library makes this an absolute breeze too, so I would consider looking there first.

Paul Deen
+1  A: 

You could use the protected configuration built into .Net. See Encrypting Configuration Information Using Protected Configuration in the MSDN docs. One of it's raison d'etres was to encrypt data such as connection strings in config files.

jbloomer
A: 

I don't think that encyrpting the password by any means is going to solve your problem. If the user has to send the password to server, and the password is located on the box, then by definition the user running the application must have access to the password and be able to decrypt it. Otherwise, you wouldn't be able to authenticate them. This means that there will always be a way for the user to get at the password, regardless of where you store it.

I can think of 2 ways that could possibly work, but I'm afraid they're not exactly what you're looking for.

  1. Remove the requirement of having the user send the password to the server by using some sort of local proxy (for example using a WCF windows service) to take your winform requests and then send them on your behalf to the DB server. If you install the service using an account different from the user's account, then you can secure the password by any of the means mentioned in the other answers. They key here is to make sure the application user does not have access to the resources that the service account needs to decrypt the password.
  2. Don't store the password in the web config. Assign each user a different user account and password at the database level and have them type it in when they log in.
TskTsk
Hello, thanks for your answer. Having the data access in a separate self-hosted service looks like a nice way to go (in fact, it would be easy to implement, provided that a have already put all the data access functionality behind a facade. However, I've been doing a little research about self-hosted wcf services, and found that Microsoft doesn't recommend that option for production environments. What do you think about that? do you know about any production system using it? I'm asking because I'm quite new to WCF.Thanks!Bernabé
Bernabé Panarello
If you host it in the same application, AFAIK, it will run under the same user account, which is not what you want. I would suggest hosting WCF as a windows service, since it's easy to secure, runs locally and you don't have to install anything else on the box, like say IIS. Here's a link to the MSDN article that describes your hosting options, pointing specifically to hosting it as a windows service. http://msdn.microsoft.com/en-us/library/bb332338.aspx#msdnwcfhc_topic4
TskTsk
Exactly, that's what I meant when i was miss-using the term "self-hosted". In the article you just posted they talk about "limited high-availability features" when they compare windows service hosting with IIS hosting. But they are not very specific about it, i don't know weather that could be important in my case, a branch could have no more than 20 simultaneous users.
Bernabé Panarello
It depends on how you plan on deploying the proxy. If you deploy one windows service alongside with the application to each user, then you don't have to worry about it. If you plan on deploying one proxy per branch, then it would make sense to deploy in a manner that would allow you have redundancy.
TskTsk