--On 10/01/00 01:05:10 PM +0200 Kaare Rasmussen <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
