We have applications running on Windows 7 Pro Servers in the field. They may be unattended and therefore insecure. They connect to Sql server in Azure. We are trying to figure out a way to secure the connection string, which currently is in plain text. We can encrypt the string but that just moves the issue to protecting the key. These are not Web applications. Our principle concern is not that the machines will be stolen but that the login will be exposed. We can use obfuscating technology like ConfuserEx to make it very difficult to find the unencrypted string but is there a best practice for this? I understand that SAML, WSFED, OAUTH, OPENID are the supported Protocols used by Azure AD for authenticating application requests but I think it's a big hill to climb to incorporate in non-Web applications.
1 Answers
I think you may be trying to protect the wrong thing.
Considering this is an application that could well be subjected to sustained attack by an adversary you should consider your connection strings compromised because no matter what sort of measures you put in place at some point in your application there needs to be a plain text string to connect to. A determined attacker will discover that.
What you should be putting time into protecting is your database. You should be able to print your connection string on flyers and stick them to the side of the machine and still not have to worry about data security.
If you grant every connection to your database root access, then you have got problems. If however you have carefully defined database roles, where the only data they can access is the data they should have access to. Then all that user can do is access data they could have accessed from the application anyway.
Make sure you have audit logs that you can review and see look for unusual activity (this is something that Azure have recently started doing). An attacker will get lots of access denied errors as they test the limits of the account they've got. Learn to spot them.
Of course it would be much better to have an API interface where you can have some manner of authentication and verification, but I understand that sometimes we have to work with what we've got.
TL;DR
Don't bother trying to do anything apart from the simplest for of encryption / obfuscation. Just make sure that when someone gets your connection string they can't do any damage with it. Lock down your database. Audit. Look at Audit, Often.
-
We are working distantly on an API interface. But for now, yes, we can only work with what we have. I provided some basic encryption. We have to examine our db user roles. THANKS!!!!!!!!!! – Ron Apr 07 '16 at 17:29