I tried to find this in the archives. If I missed it, my apologies in advance.
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
-- 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?
http://metalbunny.net/ References, tools, and other useful stuff... Check out the new Metalbunny forums at http://forums.metalbunny.net/
-- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
