views:

67

answers:

3

I write test automation and scripts that require windows authentication to the domain to access.
I don't like keeping them in the app.config because they are available in plain text.
I don't like prompting for input because then it isn't automated anymore.
If I hard code them in the assembly they are visible from .Net Reflector and they get checked into source control when I commit the .cs files.
Is there a pattern / practice that makes it easy to use configured usernames and passwords without exposing them.

This also applies to web sites that have credentials to log in and databases the use either windows authentication or sql server authentication to connect.
Any advice would be greatly appreciated.

+1  A: 

You can use Convert.ToBase64String() and Convert.FromBase64String() with hard-coded passwords to provide basic obfuscation.

If you really want something stronger, use a symmetric-key algorithm like e.g. Blowfish, but it's overkill and you'd still have to store the key somewhere.

Frédéric Hamidi
This sounds like a workable solution specifically the encryption and storing the key somewhere only the automation would have permission to get to.
Jeremy E
+1  A: 

The process that runs the tests could them as an authenticated user. That way, you only have to enter the username and password when setting up the service/scheduled task/etc. Of course, if you have to actually input credentials as part of the test, then this won't help out.

Jacob
You could take this a step further and setup an encrypted file on NTFS that contains the passwords for the SQL server logins. The user account running the schedule task would be able to read the contents of the encrypted file. Base on my limited understanding of NTFS encryption, it can configured to limit access to that file from other accounts.
poke
Or the test user could just connect to the SQL databases using Windows authentication; that way, you don't have to read any passwords.
Jacob
+1  A: 

Couldn't you use DPAPI to protect it?

There's an interesting MSDN article @ http://msdn.microsoft.com/en-us/magazine/cc164054.aspx

dotalchemy