That doesn't sound a good idea at all. Anyone can view the (HTML) source of
a web page, and can pick anything they like out of it.

Having validated a user, by means of password or otherwise, I would create a
session code, (use MD5, or something), and embed this as a hidden field
within the HTML. Arrange that the life of this session code is short (time
out activity after x minutes). Log any changes,with this code, against the
alleged user. If you are paranoid, you can generate a new code for each
page, but this fails if the user clicks on 'Back'.

Its something like using cookies, but works if cookies aren't enabled.

You must realise, however, this is not very secure. Its better that
re-broadcasting the password, however, and shows you are taking precautions,
if someone tries to sue for damages.

I hope this helps.

- Roger -

----- Original Message -----
From: "Grierson, Garry (UK07)" <[EMAIL PROTECTED]>
To: "Roger C Haslock" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, September 18, 2001 3:20 PM
Subject: RE: Security Suggestions Please!


> 1) Ok point taken.
>
> 2) Mabey a little unclear here: The script 'prints' a HTML page if the
> password is accepted. When an option is selected from the HTML page it
calls
> another script passing the password data originally passed to the current
> script as part of the HTML FORM information.
>
> E.g.
>
> (HTML Input FORM)
> <form action="../scripts/password.plx" method="POST">
>     <blockquote>
>         <h3 align="center"><font size="4" face="Arial"><b>Please
>         enter an authentication Password:</b></font></h3>
>         <p align="center"><input type="password" size="20"
>         name="password"></p>
>     </blockquote>
> </form>
> |
> \/
> (passwords.plx Script One)
> print "Content-type: text/html\n\n";
> use strict;
> use CGI;
> my $q = new CGI;
> my $password = $q->param( "password" );
>
> if ($password eq 'password'){ #only an example#
> print <<HTML_SCRIPT1;
>       <html>~~~~~~~<FORM(s)> To Run Script Two, Three , Four ,
> etc.</FORM>~~~~~~~
>
> It works but how secure is it assuming nobody is going to see the
> 'password'?
> > -----Original Message-----
> > From: Roger C Haslock [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, September 18, 2001 2:42 PM
> > To: Grierson, Garry (UK07)
> > Subject: Re: Security Suggestions Please!
> >
> > (This is not a perl/cgi question)
> >
> > 1)
> > It is easier to manage changes if data is held in a database. By similar
> > triangles, it is easier to manage security if data is held in a
database.
> >
> > 2)
> > I don't understand the question. Exactly how do you propose to pass the
> > password between scripts?
> >
> > - Roger -
> >
> > ----- Original Message -----
> > From: "Grierson, Garry (UK07)" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Tuesday, September 18, 2001 11:22 AM
> > Subject: Security Suggestions Please!
> >
> >
> > > 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.
> > >
> > > 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!
> > >
> > > --
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> > >
>
> --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to