Friday, March 20, 2009

Password Encryption in VSTS

Of course, I work at a company that, for some reason, does not like the idea of unencrypted passwords being available to anyone that has access to the Webtests that we are creating.

Have I missed any built-in option that provides this functionality? If not, can I add this to the wish list?
-------------------------------------------------------------------------------------------

that would be a nice feature.. LoadRunner supports something like that so you can encrypt passwords, either in the test itself, or your datafiles..

Of course it's really just a speed bump to anyone who has access to the tool, since they could run it and look at the request details in the test results to see the acutal values being submitted.. (presuming they know or learn enough about how the tool works to do that)

Even if you can encrypt them, there is a very Strong argument here for a complete seperate set of userID''s and passwords on your test environment that are not used anywhere else, especially not in a production environment.
-----------------------------------------------------------------------------------------------


That's right, thanks Chuck. To be clear, encrypting the passwords does not make them secure, it just obfuscates them.

To really secure the password, we would have to tie the encryption algorithm to a machine, specific user, or use a shared secret (a cert file) that unless you had the cert file you couldn't decrypt the password. Or provide a central secure store for the user names and passwords.

We would also have to ensure the password does not show up in any log file or post request display.

But I agree Lewis, obfuscation is definitely the first step. We will likely go up to the shared secret option in our next release.
Ed.
---------------------------------------------------------------------------------------------

This is one of those instances where I think you REALLY need to take the view that any and every account in your test environment is presumed to be insecure. Those accounts should have no rights outside the test domain, they should be used ONLY for the test domain. Because ultimately the more you work to make it so those things are 'secured' the more difficult you make it to work with the tool and diagnose things if something goes wrong.. detecting a typo in a password becomes nearly impossible for example.

Ultimately the test system has to be able to submit the password for authentication, which pretty much means that anyone who can run the tests (perhaps in a debug mode) can get to the passwords. In that respect it's a lot like trying to secure a CD or DVD etc (and anyone who's been following that scene knows how effective those efforts have been).. You've also got run logs, recorded values, fiddler logs, and a host of other places a password could get stored in the clear simply because the system didn't know (or know at that TIME) that it was a password and should be obscured.

So were it me I would pretty much plan on a presumption that all test accounts are not secure, and thus limit them to the test sandbox. I think any encryption you have available is mostly to make your corporate IT folks happy, and to comply with any company directive that no passwords be stored in cleartext EVER.. (which is a not unreasonable policy)

Speaking of which, for sites not using integrated security (eg. most public websites) it's not a bad idea to peek at the db and see how user passwords are stored for your system.. If it's not at least something like a salted hash, then somebody needs a lesson in basic security
------------------------------------------------------------------------------------------------

Someone messing with your test environment and invalidating your results? why when would that ever happen?

Yeah I so Totally get where you are coming from in that respect.. and preventing some 'well meaning' person from 'helping' you with your testing is a great reason to be able to obfuscate passwords in scripts and script data..

(Note that 'helping' here is used in much the same way that a cat will 'help' you read a book by either laying ON the book, or otherwise interposing their body between your eyes and said book..)
------------------------------------------------------------------------------------------

No comments:

Unix/Linux Commands

  Flow control Syntax break Exit a loop. continue Exit the current iteration of the loop and proceed with the next iteration. Ctrl+C Key com...