Strategies for safely storing and using user credentials testing environments

Question

Problem

I am setting up a set of e2e tests on an existing web-app. This requires automated login on a login-page (mail & password). So far, as I am still developing the tests, I have been putting the test account credentials in cleartext in my test scripts. I have been removing the credentials manually before each commit, but it will not hold for proper automated testing on a server somewhere, nor if all the developers should be able to run tests from the comfort of their own computers. Furthermore, the tests need to be able to run with several different sets of user credentials, and credential safety is critical. Since we need to test for access rights, it seems that we cannot avoid having at least one test account with access to confidential data.

Question

So my question is: What strategies do you know of, or use, for safely storing and using test credentials in testing environments on developer machines, separate servers, or both?

Prior research

I have spent a few days looking around the web (mostly StackOverflow, and many attempts at using my Google-fu) as well as asking colleagues, but without finding any known and used strategies for handling and storing credentials in tests. I reckon that many skilled programmers must already have solved this problem in numerous ways.

StackOverflow kindly suggested these somewhat similar questions, which offer some interesting strategies:

• Safely storing credentials when I need to retrieve the password for use, where the accepted answer recommends encrypting the configuration file. It seems like a very interesting idea, but it is unclear to me how well this distributes across servers and individual developer computers, and how the logistics of this could be handled.
• Storing credentials for automated use, where the asker responds to themself by stating that they simply put the credentials as cleartext in a file on their password-protected server. This might work for a single server, but I do think this is problematic if a number of local developer machines or separate test servers will be used for testing.

Case specifics

I think the question is of general interest regardless of the implementation details, but as they might be of interest they are provided here anyway.

I am using protractor for testing AngularJS apps, and am considering Grunt for further test automation. We plan on hooking the tests up on our Git server, and have it run tests at each commit to the master branch, so that we know it is never breaking. Or, not breaking during our tests, at least :)

Answer 1

I'm not sure what you mean when you say 'Strategies for safely storing and using user credentials testing environments'. You state that your tests need to be run with different sets of credentials. If your test is able to get to the credentials in clear text, so is any other application/user running under the same account.

Sure, you can encrypt the file storing the passwords, but you'd need to store the encryption key somewhere in the application or on the machine for the application to be able to decrypt it.

You could use asymmetric encryption to encrypt any credentials with the public key and only give access to the private key to the account running your tests. But still, anyone being able to log on under the account that runs your tests would be able to decrypt the credentials file and get to the passwords.

The best option is to not use confidential data in testing. I work for a company doing medical software, and we have a test domain in which we set up our software with well-known accounts and use fake data to test it.

Or if you want other developers to be able to run the tests under their own credentials, you could consider switching to Kerberos and avoid passwords all together.

Answer 2

I agree with the above answer, you can create a key, store it somewhere and use. Else you can got for encryption, I found a link which may be helpful for you. http://docstore.mik.ua/orelly/java-ent/security/ch13_05.htm