At 12:22 PM 9/18/2001 +0200, Grierson, Garry (UK07) wrote:
>I have to secure a newly developed web search service that deals with
>sensitive fiscal information, this originally consisted of Perl scripts that
>called html pages or other scripts. The default page ran a rudimentary login
>script that launched a variety of html pages or further scripts, the html
>pages in turn also ran scripts, one page also runs an IDC search.
>
>To disallow direct access to the html I have 'moved' this inside the
>appropriate Perl scripts so a valid password displays the html page and an
>invalid password returns you to the login script. The password is passed
>between the scripts using the post method so it won't show up on the URL
>bar.
>
>I have two questions.
>
>1) What benefits if any are there from checking the entered passwords
>against a file or database table as opposed to having a valid password or
>list of passwords held within the initial validation script?
> The password will be changed regularly and the server is unlikely to be
>changed to displaying the script text be mistake is unlikely.
This depends on your security model and whether you believe in security
through obscurity.
>2) What if any dangers are inherent in passing the password between the
>scripts to verify the users access?
> This is an Intranet site so the only sniffers should be people with
>colds!
Do you trust your employees? I might if I have 5, but a company of 3000
would likely and probably should not. Corporate espionage and sabotage is
definitely a real threat in corporations world-wide and should not be ruled
out even if it seems improbable.
That doesn't necessarily mean you need SSL client certificates. But it does
mean that you should match your security needs with your risks. You really
have not laid out the risks of what your company loses if these areas of
your web site are exposed.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
