Its not that much overhead to check it each time...but I would store the
username (not the password) in the session along with an 'access_level' and
some hash value to uniquely id that person/account each time (read the hash
from the db before authorizing any alterations to the data). Check the
session data on each page/action in the db to ensure the user has the
authority.
Administrators should never be allowed to create db accounts...they could
be allowed to create access accounts in a application specific table.
Granting other the right to create db accounts opens the system to all sorts
of POTENTIAL problems. Admins should only be allowed to create accounts up
to a certain level, not including (below) their own..nor should they be
allowed to modify their own record to alter their own privs.
The true db user accounts should be tightened to the absolute minimum set of
priv required to do the activity of that user level (ie basic user (connect
/ select...ie view only), med user (connect, select, insert and update)
should cover 95% of the interaction) and advanced users (connect, insert,
update and [delete (maybe, depending on application goals)]).
There should be only one superuser account that handles all other areas of
db admin (backup, recovery, creation of tables/indeces, etc) and only one or
two people should have access to this account.
As for the production system, all actions should be logged to a table
indicating the user, nature of the change, datestamp to provide a proper
audit trail. This table should only only select and insert privs on it, so
that even by accident, nothing can be deleted
bastien
From: "Sean Mumford" <smumford@xxxxxxxxxxxxxxxxxx>
To: <php-db@xxxxxxxxxxxxx>
Subject: Database storage and Sessions
Date: Fri, 10 Feb 2006 16:05:15 -0500
Hi guys,
I'm trying to create a small, publicly accessable database where security
is
a concern since want some users to have administrative access and others
not
to. The backend is MySQL 5.0.18 with PHP 5.1.2 on an Apache 2.0.55 server,
and I am curious as to how much my session code and my database should
interact to achieve a good balance of security and speed/overhead. I have
come up with several approaches:
1. Use sessions to send the username and password from the website to the
database, where the database will authenticate it and allow that user to
log
in with pre-defined privaledges. Administrators could create database user
accounts.
2. Use sessions to store usernames and passwords completely in PHP, and
then
have a single non-administrative account that the PHP would use to access
the database. A similar method would be used for administrative accounts as
well.
3. Store all session-related information in the database (might be faster
than using PHP to store the info?).
As I said before, i'm trying to implement a reasonable amount of security
without significantly impacting the overal speed of my system (frontend &
backend). Any advice?
-Sean
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
