Test-suite for a password protected website

[leif.eriksen at hpa.com.au]

Another option that is 'somewhat' secure is to set the username and 
password in environmental variables, if you are using an OS that 
supports that concept, and you are testing in a way that supports 
reading your envirnment.

The env vars have a lifetime of the shell you created them in (and any 
subshells you may have spawned, if you EXPORT them - if your shell 
supports that concept). So once defined, you can test all day if the 
shell lives that long.

Have the Test::Harness scripts get the values from the env vars using 
the %ENV hash.
<code>
use Env qw(USERNAME PASSWORD);
...
if (login($ENV{USERNAME}, $ENV{PASSWORD})) {
    ok(some_test, some_result);
    ...
}
...
</code>

If you avoid the temptation of putting them in your 
.login/.localrc/.bashrc/<whatever>, but just define them before you 
start testing, you have values that last until the shell is exitted 
from, local to your shell and not readily readable by casual system 
hacker - unless you walk away from your console...

Leif

David Dick wrote:

> Interesting problem that i have encountered.
> If i have the time, it's good to be able to automatically and quickly 
> validate a system's integrity by having a automated test suite (using 
> something like Test::Harness, etc).  However, from a security 
> viewpoint, how do people cope with username / passwords.  I seem to 
> have hit a bit of a roadblock, in that i can test the business logic 
> of a system easily, but to be able to say
>
> ok($response->code() eq '200', "My password protected web page is 
> operational");
>
> i think i need to either
>
> 1) embed a valid username / password into the test script.
>
> This seems just awful, more so if i want to package something up and 
> release it
>
> 2) store my passwords in a decryptable format and decrypt a suitable 
> one when the time comes
>
> This seems a bit better but where do i store the decryption keys, and 
> how secure is a system that you can decrypt passwords anyway?
>
> 3) prompt for the username / password when the script runs
>
> This of course makes it impossible to run without human intervention 
> (or Expect, in which case we have returned to 1.)
>
> 4) disable username / password requirements during testing
>
> Fine, except for a live environment
>
> Personally i think option 3 is the best compromise i can think of, as 
> it does not require any passwords to be included in the test-suite or 
> accessible from the test suite and if automation is desired then you 
> can use Expect.
>
> Has anyone come up with a cool way of cracking this particular nut, or 
> is it an area that just requires tradeoffs?


-- 
Leif Eriksen
Senior Analyst/Programmer

HPA
Direct: +61 3 9217 5545
Fax   : +61 3 9217 5702

http://www.hpa.com.au/




**********************************************************************
IMPORTANT
The contents of this e-mail and its attachments are confidential and intended
solely for the use of the individual or entity to whom they are
addressed.  If you received this e-mail in error, please notify
the HPA Postmaster, postmaster at hpa.com.au, then delete 
the e-mail.

This footnote also confirms that this e-mail message has been swept for
the presence of computer viruses by MimeSweeper.  Before opening or
using any attachments, check them for viruses and defects.

Our liability is limited to resupplying any affected attachments.

HPA collects personal information to provide and market our services.
For more information about use, disclosure and access see our Privacy
Policy at www.hpa.com.au
**********************************************************************