At 23:36 01-11-2004, Eric Cranley wrote:
I tried to find this in the archives. If I missed it, my apologies in

I'm developing an intranet for my company, and we are planning on putting
sensitive information on it. I've already setup a login system using
sessions, but I'm not sure how to manage and store permissions, such as who
can view commissions, reset user passwords, etc. I've devised two methods,
but I have a feeling there's a better way to do this that I'm not thinking
of. I'll be storing these permissions in a MySQL database.

My first idea was a single field with the SET datatype. This allows for a
user to have multiple permissions, but makes it hard for other employees to
add permissions later, if they decide to restrict a previously open access
page. (I should mention that I'm the only person here who knows how to
adjust a table in MySQL, and I won't be around forever.)

My other idea solved the previously mentioned problem. I could create a
second table with employee permissions. It would have two fields,
employee_id and permission. Every employee would have one row for every
permission they had. I could also create a third table of page names and
required permission to view it, so if someone later decides that only
certain people should view a page, they can change it without coming to me.

What do people think of these ideas, and is there a better way to do this?
Thanks in advance.

Eric Cranley
IT Specialist
Willis Music Company

Firstly, the built-in PHP sessions are not the best to secure sensitive information because of how they generate and maintain the sessionIDs, they're fine for keeping information between page scripts, but not recommended for controlling access to anything. I always recommend against using them for anything that requires login. Instead, my recommendation, and that of several others, is to use a session table in the database, where the sessionID you generate is paired with the actual userID, and the sessionID is then sent to the user in a cookie. How to generate the sessionIDs are really up to, the important part is that they're unique. In my systems, I use the user's loginID, the user's browser agent ID, as well as other gathered information, then piece all of this together into 1 string, MD5 it, then add a very long string of random characters to it, md5 it again, and then chop out 256 chars, and use those as the session ID. The ID is then stored in the session table, with the userID, login time, login IP, and other data needed for security purposes. It also has a field for last action time, which is updated on each page load. When a user is inactive for 1 hour (in my case, you can reduce this to 20 mins or less, although going under 20 mins is not recommended as it may be impossible to read a page without having to login again to view the next), the ID expires. If the same user logs in from a different browser session, a new session ID is generated, and the old ones killed and terminated, making all the other sessions invalid. Every time a user logs in, and out, this information is logged. On every login and manual logout, the system clears the session table for all session IDs for that user. The logged information is stored in seperate table.

The system I made checks the cookie against the active sessions, and lockout the page entirely if it can't find a match. Meaning all it loads is a login box, the reduced menu for non-logged in users, and a "You do not have permission to view this page". I also make my scripts so only the parts of a page or form that the user can actually use is generated and loaded. Thus they can't see the options they don't have permission to use. This reduces the risk of people knowing that a certain functionality exists, and thus try to gain access to that functionality.

Secondly, having a boolean field for each perm in the user table is my recommendation. You can also do group based perms, where you have a table with a row for each group, and a boolean for each perm that group can be set to. Or a combination of both. I use both user and group based perms, where the user "allow" settings override the group's "not allowed" settings. In my forum system, I've got a per forum based perm system, where each forum has a row for each group in a seperate table. This means that each group can have different perms for each forum. This method is easily adapted to other kinds of systems.

Not sure this helps, but hope it does. Personally I would not use any publicly known method of maintaining sessions for anything containing sensittive information. The risk of someone figuring out how to circumvent it is too great. My forum/community system login covers large amounts of personal information, as well as private correspondance. I've made it so that even the system administrators do not have access to any of this information unless the users grant their profile access to it. Only way to see it would be to go through the database itself, and as a policy, I don't allow anyone except me within 6 feet of the running system database. Securing sensitive information goes beyond just having a fancy login system, you'll need to control access to the system that stores the information as well.


Rene Brehmer
aka Metalbunny

If your life was a dream, would you wake up from a nightmare, dripping of sweat, hoping it was over? Or would you wake up happy and pleased, ready to take on the day with a smile?
References, tools, and other useful stuff...
Check out the new Metalbunny forums at

PHP Database Mailing List (
To unsubscribe, visit:

Reply via email to