You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by Kaare Rasmussen <ka...@webline.dk> on 2000/10/01 13:05:10 UTC
Secure way of logging in
Hi
I'm looking for a way to log in to a database application. The database is
PostgreSQL, and it would be nice if the solution would use the database for
authentication.
The webserver is apache. I could use htaccess, but I really need to know
who's logging on, because the user is only allowed to see his own data from the
database. Also, as stated above, it would be nice to use the database server so
I only have to maintain information one place.
I'm concerned about how to pass the login information to the database pages,
without the possibility for others to fake this login information.
I hope someone has done this and will share
Regards,
--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2582
Howitzvej 75 �ben 14.00-18.00 Email: kar@webline.dk
2000 Frederiksberg L�rdag 11.00-17.00 Web: www.suse.dk
Re: Secure way of logging in
Posted by Ragnar Hakonarson <ra...@conquestnetwork.com>.
Take a look at Apche::TicketAccess. That module does the job..
On Sun, 1 Oct 2000, Ilia Lobsanov wrote:
> Rob, you shouldn't rely on JavaScript for this. And I don't see why you need
> cookies for that.
> Just use SSL if you don't want a sniffer to intercept the password.
>
> ilia.
>
> ----- Original Message -----
> From: "Rob Tanner" <rt...@cheshire.onlinemac.com>
> To: "Kaare Rasmussen" <ka...@webline.dk>; <em...@perl.apache.org>
> Sent: Sunday, October 01, 2000 12:20
> Subject: Re: Secure way of logging in
>
>
> > --On 10/01/00 01:05:10 PM +0200 Kaare Rasmussen <ka...@webline.dk> wrote:
> >
> > > Hi
> > >
> > > I'm looking for a way to log in to a database application. The
> > > database is PostgreSQL, and it would be nice if the solution would
> > > use the database for authentication.
> > >
> > > The webserver is apache. I could use htaccess, but I really need to
> > > know who's logging on, because the user is only allowed to see his
> > > own data from the database. Also, as stated above, it would be nice
> > > to use the database server so I only have to maintain information one
> > > place.
> > >
> > > I'm concerned about how to pass the login information to the database
> > > pages, without the possibility for others to fake this login
> > > information.
> > >
> >
> >
> > If you're willing to use cookies, have I got a method for you!!. For
> > basics on database authentication in conjunction with cookies, read
> > through chapter 6 of the eagle book. For making that authentication
> > interaction with the browser with the browser secure, what I do is an
> > MD5 challenge/response to the browser using a bit of javascript.
> >
> > First go to URL <http://pajhome.org.uk/crypt/md5> where you will find
> > the MD5 algorythm in javascript and copy it.
> >
> > The interaction with the browser is this: send a signon screen with two
> > embedded forms -- one that has the text input fields for username and
> > password, and one that has hidden fields. The hidden fields are used
> > to convey the username and the MD5 hash of the password. It's this
> > second form of hidden fields that gets submitted (otherwise you'd send
> > back the plain text password along with the MD5 hash and that kind of
> > defeats the purpose -- remember that in javascript you can't write to
> > or clear a password entry field)
> >
> > The other piece of this trick that make it work is the challenge. Also
> > in a hidden field, send some random data. I use a 64 byte random
> > string. In the javascript, first I make an MD5 hash of the password,
> > and then I make one long string of the user name, password hash and the
> > user plus the challenge string, and that's the hash that I send back to
> > the server along with the user name in plain text. At the server end,
> > when you authenticate the user, you simply perform the same process.
> > You will need a password file containing hashed passwords (the system
> > password file won't do -- those passwords are encrypted with UNIX
> > crypt), as well as a way of knowing what the challenge was you sent to
> > the browser. I send a serial number to the browser as well in a hidden
> > field and that allows me to lookup the challenge string in the
> > database. At that point, you simply do on your end what the javascript
> > did and if the end results match, the user is authenticated.
> >
> > What makes this secure is that a would-be sniffer never sees the plain
> > password -- it simply never hits the wire. Since the random challenge
> > is random (dah!), for all intents and purposes, without already knowing
> > the shared secret (i.e., the password), the response to the challenge
> > is random. Tus, the would-be sniffer/hacker still have to use the good
> > old brute force method, and since MD5 passwords are not limited to 8
> > bytes like UNIX crypt, brute force gets a lot harder (and even more so
> > if this hacker didn't catch the challenge as it came down the wire).
> >
> > -- Rob
> >
> >
> >
> > _ _ _ _ _ _ _ _ _ _
> > /\_\_\_\_\ /\_\ /\_\_\_\_\_\
> > /\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT,
> > /\/_/__\/_/ __ /\/_/ /\/_/ PROFUNDUM VIDITUR
> > /\/_/_/_/_/ /\_\ /\/_/ /\/_/
> > /\/_/ \/_/ /\/_/_/\/_/ /\/_/ (Whatever is said in Latin
> > \/_/ \/_/ \/_/_/_/_/ \/_/ appears profound)
> >
> > Rob Tanner
> > McMinnville, Oregon
> > rtanner@onlinemac.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> > For additional commands, e-mail: embperl-help@perl.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
Re: Secure way of logging in
Posted by Kaare Rasmussen <ka...@webline.dk>.
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: kar@webline.dk
2000 Frederiksberg L�rdag 11.00-17.00 Web: www.suse.dk
Re: Secure way of logging in
Posted by Rob Tanner <rt...@cheshire.onlinemac.com>.
--On 10/01/00 04:05:39 PM -0400 Ilia Lobsanov <il...@lobsanov.com> wrote:
> Rob, you shouldn't rely on JavaScript for this. And I don't see why
> you need cookies for that.
> Just use SSL if you don't want a sniffer to intercept the password.
>
> ilia.
>
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
javascript algorythm does an excellent job, and it does the MD5 hash
correctly at the browser. Also, it works on any browser that does
javascript (no secure javascript or ssl signatures, etc, required). If
your concern is that the script could be sniffed, the MD5 hash
algorythm itself is widely available and security by obscurity is not a
good security model.
As far as ssl, there are several issues. Depending on your budget,
even the $125 for a Thawte certificate maybe too high. Also, on slow
links and older machines, SSL is more expensive timewise to run. Since
the original poster said nothing about securing the browser response
itself but only access to it (which is very common for commercial data
services although I don't know what kind of data Kaare Rasmussen in
concerned with in the original post). Also, I understand that
encryption is not legal in some Europen countries. I'm not sure which
ones and I have no idea what the rationale is, but MD5 password hashes
might conceivably skirt that issue.
On the plus side, in the US the old RSA patent became history last
month, either expiring on Sep 20 or valid through Sept 20. In any
event, it's now in the public domain and you can set up secure servers
without an RSA licensing issue. I don't know if there are other
international patents on the RSA algorythm or not, so I don't know
whether Europeans (the original post was from *.dk which is Denmark)
are so blessed or not.
-- Rob
_ _ _ _ _ _ _ _ _ _
/\_\_\_\_\ /\_\ /\_\_\_\_\_\
/\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT,
/\/_/__\/_/ __ /\/_/ /\/_/ PROFUNDUM VIDITUR
/\/_/_/_/_/ /\_\ /\/_/ /\/_/
/\/_/ \/_/ /\/_/_/\/_/ /\/_/ (Whatever is said in Latin
\/_/ \/_/ \/_/_/_/_/ \/_/ appears profound)
Rob Tanner
McMinnville, Oregon
rtanner@cheshire.onlinemac.com
Re: Secure way of logging in
Posted by Ilia Lobsanov <il...@lobsanov.com>.
Rob, you shouldn't rely on JavaScript for this. And I don't see why you need
cookies for that.
Just use SSL if you don't want a sniffer to intercept the password.
ilia.
----- Original Message -----
From: "Rob Tanner" <rt...@cheshire.onlinemac.com>
To: "Kaare Rasmussen" <ka...@webline.dk>; <em...@perl.apache.org>
Sent: Sunday, October 01, 2000 12:20
Subject: Re: Secure way of logging in
> --On 10/01/00 01:05:10 PM +0200 Kaare Rasmussen <ka...@webline.dk> wrote:
>
> > Hi
> >
> > I'm looking for a way to log in to a database application. The
> > database is PostgreSQL, and it would be nice if the solution would
> > use the database for authentication.
> >
> > The webserver is apache. I could use htaccess, but I really need to
> > know who's logging on, because the user is only allowed to see his
> > own data from the database. Also, as stated above, it would be nice
> > to use the database server so I only have to maintain information one
> > place.
> >
> > I'm concerned about how to pass the login information to the database
> > pages, without the possibility for others to fake this login
> > information.
> >
>
>
> If you're willing to use cookies, have I got a method for you!!. For
> basics on database authentication in conjunction with cookies, read
> through chapter 6 of the eagle book. For making that authentication
> interaction with the browser with the browser secure, what I do is an
> MD5 challenge/response to the browser using a bit of javascript.
>
> First go to URL <http://pajhome.org.uk/crypt/md5> where you will find
> the MD5 algorythm in javascript and copy it.
>
> The interaction with the browser is this: send a signon screen with two
> embedded forms -- one that has the text input fields for username and
> password, and one that has hidden fields. The hidden fields are used
> to convey the username and the MD5 hash of the password. It's this
> second form of hidden fields that gets submitted (otherwise you'd send
> back the plain text password along with the MD5 hash and that kind of
> defeats the purpose -- remember that in javascript you can't write to
> or clear a password entry field)
>
> The other piece of this trick that make it work is the challenge. Also
> in a hidden field, send some random data. I use a 64 byte random
> string. In the javascript, first I make an MD5 hash of the password,
> and then I make one long string of the user name, password hash and the
> user plus the challenge string, and that's the hash that I send back to
> the server along with the user name in plain text. At the server end,
> when you authenticate the user, you simply perform the same process.
> You will need a password file containing hashed passwords (the system
> password file won't do -- those passwords are encrypted with UNIX
> crypt), as well as a way of knowing what the challenge was you sent to
> the browser. I send a serial number to the browser as well in a hidden
> field and that allows me to lookup the challenge string in the
> database. At that point, you simply do on your end what the javascript
> did and if the end results match, the user is authenticated.
>
> What makes this secure is that a would-be sniffer never sees the plain
> password -- it simply never hits the wire. Since the random challenge
> is random (dah!), for all intents and purposes, without already knowing
> the shared secret (i.e., the password), the response to the challenge
> is random. Tus, the would-be sniffer/hacker still have to use the good
> old brute force method, and since MD5 passwords are not limited to 8
> bytes like UNIX crypt, brute force gets a lot harder (and even more so
> if this hacker didn't catch the challenge as it came down the wire).
>
> -- Rob
>
>
>
> _ _ _ _ _ _ _ _ _ _
> /\_\_\_\_\ /\_\ /\_\_\_\_\_\
> /\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT,
> /\/_/__\/_/ __ /\/_/ /\/_/ PROFUNDUM VIDITUR
> /\/_/_/_/_/ /\_\ /\/_/ /\/_/
> /\/_/ \/_/ /\/_/_/\/_/ /\/_/ (Whatever is said in Latin
> \/_/ \/_/ \/_/_/_/_/ \/_/ appears profound)
>
> Rob Tanner
> McMinnville, Oregon
> rtanner@onlinemac.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
>
Re: Secure way of logging in
Posted by Rob Tanner <rt...@cheshire.onlinemac.com>.
--On 10/01/00 01:05:10 PM +0200 Kaare Rasmussen <ka...@webline.dk> wrote:
> Hi
>
> I'm looking for a way to log in to a database application. The
> database is PostgreSQL, and it would be nice if the solution would
> use the database for authentication.
>
> The webserver is apache. I could use htaccess, but I really need to
> know who's logging on, because the user is only allowed to see his
> own data from the database. Also, as stated above, it would be nice
> to use the database server so I only have to maintain information one
> place.
>
> I'm concerned about how to pass the login information to the database
> pages, without the possibility for others to fake this login
> information.
>
If you're willing to use cookies, have I got a method for you!!. For
basics on database authentication in conjunction with cookies, read
through chapter 6 of the eagle book. For making that authentication
interaction with the browser with the browser secure, what I do is an
MD5 challenge/response to the browser using a bit of javascript.
First go to URL <http://pajhome.org.uk/crypt/md5> where you will find
the MD5 algorythm in javascript and copy it.
The interaction with the browser is this: send a signon screen with two
embedded forms -- one that has the text input fields for username and
password, and one that has hidden fields. The hidden fields are used
to convey the username and the MD5 hash of the password. It's this
second form of hidden fields that gets submitted (otherwise you'd send
back the plain text password along with the MD5 hash and that kind of
defeats the purpose -- remember that in javascript you can't write to
or clear a password entry field)
The other piece of this trick that make it work is the challenge. Also
in a hidden field, send some random data. I use a 64 byte random
string. In the javascript, first I make an MD5 hash of the password,
and then I make one long string of the user name, password hash and the
user plus the challenge string, and that's the hash that I send back to
the server along with the user name in plain text. At the server end,
when you authenticate the user, you simply perform the same process.
You will need a password file containing hashed passwords (the system
password file won't do -- those passwords are encrypted with UNIX
crypt), as well as a way of knowing what the challenge was you sent to
the browser. I send a serial number to the browser as well in a hidden
field and that allows me to lookup the challenge string in the
database. At that point, you simply do on your end what the javascript
did and if the end results match, the user is authenticated.
What makes this secure is that a would-be sniffer never sees the plain
password -- it simply never hits the wire. Since the random challenge
is random (dah!), for all intents and purposes, without already knowing
the shared secret (i.e., the password), the response to the challenge
is random. Tus, the would-be sniffer/hacker still have to use the good
old brute force method, and since MD5 passwords are not limited to 8
bytes like UNIX crypt, brute force gets a lot harder (and even more so
if this hacker didn't catch the challenge as it came down the wire).
-- Rob
_ _ _ _ _ _ _ _ _ _
/\_\_\_\_\ /\_\ /\_\_\_\_\_\
/\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT,
/\/_/__\/_/ __ /\/_/ /\/_/ PROFUNDUM VIDITUR
/\/_/_/_/_/ /\_\ /\/_/ /\/_/
/\/_/ \/_/ /\/_/_/\/_/ /\/_/ (Whatever is said in Latin
\/_/ \/_/ \/_/_/_/_/ \/_/ appears profound)
Rob Tanner
McMinnville, Oregon
rtanner@onlinemac.com