[Tallahassee-pm] PHP authentication

[Tillman, James]

Funny you mention AOL.  That's the very reason we disabled the IP checking
in my previous project.  It was an internet-based project (not really the
norm for my current client), and we kept getting folks complaining about
getting kicked out!  Good thinking on your part to avoid that altogether.
 
As for your sessionid() function, I'd say it's practically worthy of
appearing in a William S. Burroughs or Philip K. Dick novel.  Plenty
paranoid!
 
jpt

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



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/b503ae31/attachment.htm