Balancing security with tester convenience: should you put credentials in test instructions?

Question

I'm in a small enterprise environment, a dozen or so developers, no full time QA specialist, no dedicated testing resources. Project leads and developers and subject matter experts all contribute to test case development, and test cases are executed by developers, subject matter experts, business staff who will ultimately use the software in production, etc. We execute our tests in various non-production environments, but, most of our non-production environments are populated with actual data from production. Our test case management tool is behind our perimeter firewall as are the non-production application systems under test.

Since a variety of people can execute test cases, testing is more convenient if our test case instructions are very explicit, i.e., login to https://.../login with username "BOB" and password "TESTING789!2015" ....

However, explicitly revealing login credentials, even to a test application, is a questionable security practice, and in our situation, the system under test does contain a copy of production data so it does contain genuinely confidential data. (Note the staff that we select to execute tests are staff who are authorized to see confidential data in production, but, the test management tool authorizations probably aren't managed with the same diligence with which we would manage production system authorizations, so there is potential for the test case credentials to provide a vector for unauthorized staff to login to the test system and see the test system copy of confidential data.)

Alternatives as I see them include:

1) Write test cases for convenience of testers, explicitly revealing credentials, and manage authorizations to the test case instructions to minimize the security risk. (Accept the risk that authorizations to the test case management tool probably aren't managed with the same diligence as the actual production systems.)

2) Write test cases without credentials, i.e., "supply valid username", "supply valid password", and use telephone or sneakernet to distribute passwords, and accept the risk that testers will write down passwords, and accept the risk that testers will be less willing to cooperate with testing efforts, but, possibly reduce testing-induced security risk.

3) Use shared "lastpass" or "password safe" mechanisms to distribute test case credentials, requiring testers to deal with additional complexity, and accept the risk that testers will be less willing to cooperate with testing efforts, but, possibly reduce testing-induced security risk.

What alternatives am I overlooking?

What do other organizations do about credentials in test instructions?

Answer 1

The method used at my current location is a slight variation on the suggestions above:

1. Each team member has a personal superuser login whose password is known only to them.
2. Each team member then resets passwords on users in the dev, test, and staging environments and logs in as those users. For the applications where passwords expire they usually alternate between two known, common passwords.
3. Team members also create users with known, common passwords. The known, common passwords are standard to the team.
4. Test cases will simply give the privilege level of the user required, and the team member can either user approach 2 or 3 depending on the needs of the test case.

Answer 2

In one situation when we copied production data to QA, we set passwords of all outside users to one know value. So testers can log to account of a real user in QA (with copy of the data from PROD, all settings and stuff), but don't need to know user's valid login credentials.

This will not prevent someone looking into any user's data, but will prevent tester to use learned login credentials in PROD.

So this might be valid in your situation or not, depending if you are concerned if someone looks at some specific data in QA. If so (you have say real phone numbers and you want to prevent testers from seeing them), you can scramble just those data fields for additional protection.

Answer 3

I've used option 1 and 2 on occasion. Two other options I've used are.

4) Setup test servers to not require authentication. Obviously if your test servers are identical to your prod servers this would be a huge security issue. Where we have done this all the test data was bogus.

5) Encrypt passwords. Maven 2.1+ offers password encryption.