> 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'?
How, precisely, is anyone prevented from seeing passwords? You haven't mentioned
cookies (which,
in any event, can still be sniffed and are stored on the computer), but you *have*
mentioned the
POST method as a means of securing data. I'm assuming that you are using hidden
fields. Anyone
can "view source" and see the password. This is a very, very bad idea.
Okay, so this is for an intranet and you're not worried about sniffers. First rule of
CGI
security: never, never, never trust anything outside of your script. What if someone
compromises
your firewall? What if a curious employee wants to see the passwords (one company I
worked for,
that curious employee was then tasked with creating a security department)? What if
someone comes
along later and decides to add bells and whistles to what you have developed? No one
can anyone
predict the future; You don't know what's going to happen with your code. That's why
security is
*always* important.
One problem with not securing passwords, even if the application is not secure, is
that people
tend to reuse passwords. Even if you set a password policy and issue secure
passwords, they will
often take these passwords and use them on other systems. I've heard people
complaining because
they need to synchronize their passwords *again*! If you allow these passwords to be
compromised,
someone may very well have access for a heck of a lot more than just your HTML pages.
In my
security research, I've read more than once that the majority of corporate espionage
comes from
inside the company. Your email address suggests that you work for Honeywell. They're
not a tiny,
fly-by-night non-profit. They have many employees and I would hardly credit all of
them with
goodwill.
For a *brief* overview of Web security with Perl, read
http://www.easystreet.com/~ovid/cgi_course/lesson_three/lesson_three.html (I realize,
inexplicably, that I didn't cover cookies in that!). That material also includes many
links to
other security material. Learn it all and you'll be telling *me* how to lock down a
CGI script :)
sub create_digest_from_password {
my $pass = shift;
my $md5 = Digest::MD5->new;
$md5->add( $pass );
$md5->add( $salt );
$md5->b64digest;
}
The above snippet will return a 22 character "digest" which is essentially a one-way
function.
You cannot recover the digest from it. The "salt" should be a very random string of
data that is
read from a non-Web accessible directory (don't put it in the script in case someone
gets your
code). This salt can never change.
Once you create the digest, save the digest and when someone logs in, recreate the
digest from
their login passwords. If the passwords match, you have a successful login (I write
failures to a
security log). You can then pass around the digest rather than the password. It
should require
very little change to your code.
The salt, by the way, is used to stop crackers from "brute forcing" a password.
Typically, they
use something like l0phtcrack which uses a word list to generate common permutations
of those
words to guess passwords. If your salt is
(*@&L>Nz4L*&#@&^
few, if any are going to guess it.
Also, you should probably try to use sessions instead of passing around a password
digest. It's
much more secure. If you want to see how that's done,
http://www.perlmonks.org/index.pl?node_id=101247 is an "alpha" of a security model I
developed.
Unfortunately, I can't release the final product, sorry.
Cheers,
Curtis "Ovid" Poe
=====
Senior Programmer
Onsite! Technology (http://www.onsitetech.com/)
"Ovid" on http://www.perlmonks.org/
__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
