[Tallahassee-pm] PHP authentication

Fri May 16 13:42:53 CDT 2003

That helps a ton. That is actually a lot like the system I was
picturing, except you've obviously done a bit more thought on the
expiration side of the problem. I'm very leery about coupling the system
with client IP matching, just because of the poor sods on AOL and MSN,
and all the fun proxy things both services do.

SSL is a definite, but the problem that I worry about, but few others
seem to, is the problem of a valid user executing a privilege
escalation. And that is what most systems I see seem to leave wide open.

Everyone who codes a website service seems to end up writing their own
session system. Let me take that back, I've seen session systems that
are supposed to be able to plug into anything you want to create, but
again, they just don't seem that secure. There should be a nice,
paranoid custom database driven session framework in open source, and
then we could have a great time tying all the nice web services out
there into the same backend without going insane.

Speaking of paranoid, how's this?

function sessionid()

{

// The purpose of this function is to generate a 110 digit,

// case sensitive alphanumeric session ID for the purpose of

// tracking active logins. It uses multiple entropy sources.

// Generating large random numbers can be resource intensive,

// So the upper limit of the random numbers can be tuned to 

// provide the right balance of uniqueness, and system performance.

            # Generate a unique ID based on the server clock

            $uid_clock=uniqid(1);

            # Generate a random number called $rand_num1

            $rand_num1=rand(1, 1000000000000);

            # Generate a random number called $rand_num2

            $rand_num2=rand(1, 1000000000000);

            # Calculate a md5 hash of each random number separately

            $rand_hash1= md5($rand_num1);

            $rand_hash2= md5($rand_num2);

            # Generate user_remote_info based on the client ip and port,
if they exist.

            $user_remote_info =
$_SERVER['REMOTE_ADDR'].$_SERVER['REMOTE_PORT'];

            # Calculate a hash based on the remote user info

            $user_remote_hash= md5($user_remote_info);

            # Combine the above hashes, and unique id's to create a
relatively

            # unique and hard to guess string

            $nsessionid=
$rand_hash1.$uid_clock.$rand_hash2.$user_remote_hash;

            return $nsessionid;

}

-----Original Message-----
From: Tillman, James [mailto:JamesTillman at fdle.state.fl.us] 
Sent: Friday, May 16, 2003 1:31 PM
To: Phillip Tyre; tallahassee-pm at mail.pm.org
Subject: RE: [Tallahassee-pm] PHP authentication

Yes, the silence has been unfortunate.  I've been up to my ears in work
these last few weeks.

In my own previous work, I have been able to go a little further than
simply setting a cookie in the browser and trusting it from then on.
What I've done in the past with my own security systems was:

*        Create a large randomized string (20 chars min.) and use that
value as a session key (I call it a "ticket"),which gets stored in the
database as being tied to a particular user, and is then sent to the
browser as a cookie along with another cookie indicating the username.

*        Each "ticket" has an expiration time of about 15 minutes (not
an actual HTTP cookie expiration time, but a time my code keeps track
of). This time can be as long or short as you want, depending on how
paranoid you are.

*        Each time the browser accesses the web app, my server side code
verifies that the cookie value matches the current ticket that is stored
in the database for that user (or that is cached on the web server
somehow -- it doesn't have to be a database, see Apache::Session), and
that the "ticket" hasn't expired.  

*        If the ticket has expired, a new one is generated, stored in
the db, and issued to the browser without the user being any the wiser.

*        If an invalid ticket is passed in, all valid sessions for that
user are deleted, and the user is asked to log in again.

The end result is that it becomes very difficult for someone to hijack a
user's session because they must be able to send in the usercode cookie
and the ticket cookie, which is very hard to guess.  Even if they manage
to do that, they'll only get 15 minutes (or whatever I've set the expiry
to be) before they blow up the session and force a login, since either
their browser or the legitimate user's browser will send an invalid
ticket once a new one gets issued and the system will kick them both
out.

This has worked very well for me in the past, and when coupled with a
method for IP address matching, it becomes even more secure.

Essentially, if you need more security than this, I'd say it's time to
add SSL into the mix.

hope this helps!

jpt

 -----Original Message-----
From: Phillip Tyre [mailto:phillip.tyre at fcul.com]
Sent: Friday, May 16, 2003 2:16 PM
To: tallahassee-pm at mail.pm.org
Subject: [Tallahassee-pm] PHP authentication

	Has anyone had any experience with a custom perl, or PHP based
authentication framework using mysql as the back end? I've done some
looking, but all the ones I've seen tend to make the same basic
assumptions. Once you authenticate the user, and set a cookie, then you
can trust all the cookies that are set for that user (admin status,
username, etc).

	I'm really looking for something more secure, where the actual
session table in the database would hold the permissions, and based on a
matching session, the table would be queried to retrieve the
permissions.

	Am I way off base on this?

	Phillip Tyre

	P.S. This message brought to you because of the heavy silence
this list has experienced since the last time I posted.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/tallahassee-pm/attachments/20030516/a734b494/attachment.htm