If you really want security then you should probably look into SSL. For most purposes a login system that uses session variables should be sufficient.

Probably not then [smile]

This is how my login system works:

I have a database for storing information about my users. Among other things it includes two fields named CookieID and LoggedIn. CookieID is a unique 64 character key that I create for the user (which may be changed) and store on the user's computer in a cookie. LoggedIn is true if the user is logged in, false if not.

When a user comes to my site I first try to see if they have a cookie with an ID in it and if so I use that ID to make a guess at which user this is by searching for that ID in my user's database. If the ID is found and LoggedIn is true then I set two session variables: the user's ID (not their cookie ID but their actual ID) and the SHA1 of the user's password. When these session variables are set the user is logged in. If a user comes and no cookie ID is found or if the cookie ID is found but LoggedIn is false then I do not set these session variables.

When a user logs in after having been logged out then these session variables are set and LoggedIn is set to true. When a user logs out then these session variables are destroyed and LoggedIn is set to false.

Using this method users only have to log in once when they enter the site and, as long as they dont log out, they will remain logged in when they return. The danger of this system is that CookieID is essentially the password but I believe that CookieID has enough possibilities that is impractical to brute force (62^64 combinations using uppercase, lowercase, and numbers) to make it safe. As long as users log out when they leave then they will be safe as well.

Your best bet is to ensure that you use consistent methods of accessing the database which always properly escape or parameterise all queries - automatic persistence with something like DB_DataObject will do this, or using prepared queries with PEAR:DB. This will prevent SQL injection attacks (which could otherwise lead to a server compromise).

Then the biggest threads are XSS (cross site scripting) and CSRF (Cross-site request forgery). These can't compromise the server (unless used in conjunction with another vulnerability), but could compromise the application.

XSS happens if an attacker can get some of their own html maliciously into the output that another user sees, usually by creating a link elsewhere and using social engineering to persuade an authorised user to click on it - the attacker may be able to steal cookies etc.

You can protect against XSS by using a templating system (such as smarty) and instructing it to escape all variables in templates by default (in smarty, set up the default modifier).

CSRF is more difficult to protect against - essentially it's an attack where an attacker creates their own form which posts to a privileged page on your site, and assumes that either the credentials are cached in the browser (http or cookies), or the user re-enters them. This means that the attacker can get an authorised user to inadvertently trigger an action which they did not intend.

The recipe for getting around CSRF is usually putting some secret dynamic value (like a session id) in a hidden field in the form, and checking that it comes through correctly in each POST. An attacker can't correctly guess this, so they can't set the form up right.

---

As far as authentication is concerned, I'd recommend using HTTP authentication. You can use it easily in PHP and it does not require cookies or sessions.

Mark