Kaare,
Here is my solution... I use Oracle for my user authentication.
The username / password is never sent back to the client after logon and any
user attempting to access pages without logging on is denied.
A secure (SSL) form requests username & password. The receiving Embperl
page verifies the username & password by connecting to the database. If
successful, I put the Username, Password, and DataSource (my users can jump
databases) into 3 %udat fields. I then issue a redirect to the interior
site. *Every* one of my embperl pages uses a common module and calls an
init routine. This routine checks to see if there is a username, password,
and datasource in the %udat. If there is not, a http_redirect is issued
passing the user back to the logon page with a GET parameter telling the
logon page to print a nasty gram about logging in first. This prevents a
user from simply typing one my interior urls and getting access. I wrapped
my entire site with a frame to prevent the casual user from learning these
urls, btw.
When a user wants to logout, I delete the udat entries and thus they
are automatically prevented from accessing the site. Since udat data is
stored on the server with only a temporary cookie and a session id stored on
the client, the username & password never travel over the network...
A few issues... :)
I am currently storing the password in clear text in the udat. For
every page request I am currently creating a new database handle. I do this
because I want my users to connect to the database as themselves. So, I end
up with a handle for each user. A shared pool of generic handles won't
work. Apache::DBI might handle this for me, but for the moment, my load is
nowhere near high enough to worry about this issue. I'll probably use
DBI::Proxy, btw to solve this issue as I could then connection pool across
servers. So, I need the password easily accessible, which is why I keep it
in cleartext.
This setup has worked very well for me on embperl pages. It is
interfacing with non-embperl pages that has proven to be difficult.
Consider this... You have a generic cgi-bin script that you need to
execute. You want it to authenticate and you want it to be seamless for the
user. You can not pass the logon data in hidden form fields except maybe
with encryption without exposing your username/password. This is my current
(unimplemented) solution... Create an embperl page that returns the
username & password in clear text. Tell apache to only serve that page to
your internal network or even loopback. Then from your cgi script, do a lwp
request (passing it the session id cookie) and retrieve the username &
password. The data should never leave your network and besides changing the
cgi script it is fairly painless. I'm planning on using this technique to
connect to a Java servlet / applet soon, btw.
If anyone wants to know I've also solved the problem of needing the
username & password on the client in a decently secure manner. The Crystal
reports web viewer activeX control requires you to authenticate on the
browser unless you are using asp. As this email is already very long I'll
write that one up as needed.
Hope this helps,
--Chris Swinefurth
Senior Consultant
NISYS, Inc.
-----Original Message-----
From: Kaare Rasmussen [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 02, 2000 2:46 PM
To: [EMAIL PROTECTED]
Subject: Re: Secure way of logging in
Hi
> I thought about that right after I responded to the original message
> (it's amazing how insightful I get AFTER I've just pressed the send
> button). But it really depends on what your requirements are. The
Maybe I didn't explain myself very well, and maybe I'm mistaking something,
but
my main problem is not the encryption, as I have a Verisign certificate for
the
Apache server.
The problem is, how will I pass information from page a to b? Consider this:
Page a:
Username
Password
User enters these fields and they're validated. If OK, they are passed on to
page b - but how? Will a fdat entry with the username be secure enough? Or
can
a person who knows the username fake it? I believe he can, but how can I
make
this secure - I can't validate the password every time page b is called.
--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2582
Howitzvej 75 Åben 14.00-18.00 Email: [EMAIL PROTECTED]
2000 Frederiksberg Lørdag 11.00-17.00 Web: www.suse.dk
---------------------------------------------------------------------
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]
