tedd wrote:
At 1:13 PM +1100 1/23/10, clancy_1@xxxxxxxxxxxx wrote:
but I would be grateful for any suggestions how I
could make this procedure more secure.
We have given you advice that you should NOT use Cookies in any fashion
to secure your site, but you remain steadfast that you know better --
so, what else can we say other than good luck.
tedd
These are my basic guidelines - what I like to do.
It may not be the best thing for every type od web site.
1) I have a user database that has username and a password hash. The
password itself is never stored.
The password hash is sha1sum(strtolower($username) . $salt . $password)
The salt is something like 5dgudsdgh5673g and should be stored as a
private variable in your user authentication class.
The reason I have the username there to is because some passwords are
very popular, using the username when generating the hash ensures that
two users with identical password will have different hashes. This is
important if an sql injection attack ever manages to get a dump of your
user database.
You should protect against sql injection by using prepared statements
for any database query that involves user submitted data (such as
username and password) but you still want to make sure that hashes are
unique, and you do that by adding the username to the salt.
When a user successfully logs in, the unique id of the user is then
stored as a session variable.
For administrative tasks, in addition to requiring that the user be
logged in to an account with admin privileges, all administrative tasks
are in a directory that is protected by apache authentication.
So to get to those kind of pages, the user has to have a
username/password that is stored in a .htpasswd file for Apache to let
them in AND they have to be logged in as a user that has been
authenticated as an administrative user.
I personally do all login via https so that username/password combos are
never sent plain text. That's more expensive because you need to
purchase a SSL certificate. You can use self-signed but it is better to
use an SSL certificate from a certificate authority.
For session security, I have the following directives set in my php.ini
file:
session.use_only_cookies = 1
- That prevents the session id from being sent via get.
session.cookie_lifetime = 0
- That instructs the browser to delete the cookie when the browsing
session ends.
session.cookie_httponly = 1
- That theoretically denies access to the cookie from scripting
languages. I say theoretically because when testing my site for XSS
security, I was initially able to get some XSS attacks to display my
session id (tested in firefox 2 w/o noscript - noscript blocked it even
with the domain allowed), so they were getting it somehow.
Since I have secure login which is a different domain from main domain,
in my web app itself I set
if (file_exists('/srv/path/DEVEL')) {
ini_set("session.cookie_domain",".mydomain.devel");
} else {
ini_set("session.cookie_domain",".mydomain.org");
}
That way, secure.mydomain.org (which is used for login) uses the same
session variable as www.mydomain.org (used for rest of site) so that
when the user logs in, the session variable that specifies the user on
the non secure domain gets updated when the user logs in on the secure
domain.
There are several good php books that discuss session security and php
web applications. I don't remember which books I used when learning my
technique, but it would be a good idea to buy or borrow some recent
books on php web application design.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
