[Tallahassee-pm] PHP authentication

Tillman, James JamesTillman at fdle.state.fl.us
Fri May 16 13:31:00 CDT 2003


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


More information about the Tallahassee-pm mailing list