tedd wrote:
At 1:13 PM +1100 1/23/10, clanc...@cybec.com.au 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

Reply via email to