pK Categories

pK Archives

Using PHP Session Control To Implement User Authentication

A common method for determining user authentication is to use sessions and cookies via PHP Programming. It is straight forward to implement, easy to secure, and fun! Authentication can be used for many purposes in your PHP Programs, from membership login to Online data repository access. Whatever your purpose, PHP Programmers can use authentication to discern between valid web site access and access that should be denied.

First, let’s review some common uses for authentication. In almost every PHP situation, you’ll be authenticating a valid login. This may take place at the actual point of login, and/or for every page load until logout. Since initial web login means the user has not been to the site, or it’s been so long since their last visit that their last session died, we’re not actually checking session-based authentication. A minor point, but to be clear, session-based authentication occurs after initial login, once a session has been established. We’ll move on with the allowance that authentication wil be session-based.

Shopping carts are a hot spot for authentication, since you may want the shopping cart to accrue products between pages. Authentication is required to know which eCommerce customer is associated with which shopping cart. Authentication is used to determine the session ID match to the user’s connection to the server. Although people usually associate “authentication” with a password, it may be as simple as checking which shopping cart the user should be using.

Data repositories like photo clubs, music download sites, and other information archives require user authentication. Any web site that needs to limit interactivity and access, or wants to track individuals for analysis, will require user authentication. The specifics of how authentication is achieved and whether additional user and behavioral data is tracked depends on the site, the PHP Programmer and the purposes rquired to increase overall cash flow.

Whatever the case, user authentication boils down to a few simple basics. You need to track enough persistent data between page loads to identify a user and associate that user with stored information about their profile. The user profile may be nothing more than an ID, but can be as complex as a complete profile, all their shopping cart data and everything they have done with your site to date. Obviously, tracking significant amounts of information presents a potential bandwidth and load time issue. This is where simple cookies are differentiated from cookie-session systems…

When a site utilizes only Cookies, alll data is stored in the cookie. Since the cookie is apiece of data stored on the user’s computer via their browser, it puts more information into the hands of the user, which presents a security issue. When the amount of data grows large, it affects bandwidth, and likely load time, making pages seem sluggish. There are plenty of reasons to avoid storing all your data in the user’s cookie, but the decision is up to the PHP Programmer and the project requirements, which may override standard procedures.

Sessions are employed to minimize the amount of data transferred between client-side browsers and server-side parsers. The user’s browser cookie stores only the Session ID, which is an identifier string. It’s like the Session Name so it can be found and associated with the user’s connection. The Session is all of the stored data from the user’s experience, but it is stored on the web server, not the user’s browser on the client-side. Not only is bandwidth minimized, but server-side storage can increase security greatly. This does not mean your session data repository is safe!

Sessions can be broken by hackers if the session IDs are predictable, in an insecure directory, and if the user’s cookie can easily be stolen and transported to the hacker’s computer. Security is another issue, but a significant one despite the concept of “authentication” in this article.

Now, let’s get down to the function of session controlled user authentication. Once your form has been designed to submit a user name and password to the server, we can verify their permissions from various systems, especially a MySQL Database. If the user checks out as valid, we can create a session for that user that identifies their status in our system. At the simple end, we’d store the user name into their session and assume we know the user is who they logged in as. However, it’s easy to duplicate this process and the cookie could be stolen from that user. String passwords in the session is a valid approach, so that subsequent authentication mechanisms can validate more efficiently. A stolen cookie will still let the hacker access the same permissions, but will not necessarily expose the user’s password form their session… it’s fairly safe on the web server.

So, how can we protect the session data and the user’s account from hackers? hackers will steal cookies right out of the connection between the client-side bowser and the server using sniffers, snorts, and man-in-the-middle proxies, etc. These are very simple techniques of stealing data in-transit. This is why SSL was invented, so those hackers can steal all the transmitted data they want, since it’ll take them forever to break the encryption and make use of the data. Unless the hacker is hugely successful and well funded, or the SSL encryption used is poor, the transmitted data is pretty safe.

Assuming the sessions directory is correctly secured and the session IDs are random enough, we can get off of the web security subject. For good measure, we will encrypt our user’s user name and password in their session and do other great PHP Programming things to make sure their data is safe. In the least, make sure any function in the user’s profile requires re-entering their original password, which will piss-off the hackers at least a little.

Now, our user has passed our validation process and we know that person should enter the site and access whatever we offer them. Before they receive their new content, we create the session containing an indentification fingerprint that lets us track our user, separately from other users. Amidst the data we store, we have a user name and a password. Ideally we should track the user’s IP Address, browser type/details, when login started, idle time, etc. These aspects of the user’s fingerprint help you kick out invalid users, even if their base credentials check out at first.

Authentication means the user has returned with some form of credentials to be validated against a reference system. Whether you use a flat file or dynamic database system, we must be holding the keys to their cookie jar. A logged-in user returning to access a site page must first be checked out to see if they have permission to do something like look, download, upload, edit, etc. Our PHP Program must identify the user via their Session ID in their Browser Cookie. That Session ID lets the PHP Program retrieve their stored user name, password or whatever, and start the authentication process.

Authentication via a dynamic MySQL Database is most common. If the user name is alone, we do a simple user name search. Else, we search for a record that contains both the user name and the password. If the password was submitted as an encrypted string, we must obviously first decrypt it before authentication. If the user data is invalid, we can modify or delete their session and invalidate their cookie. Else, valid user is cleared for entry/access and their session may be updated with behavioral data.

For high traffic sites a PHP Programmer may opt to use persistent connection, allow continuous access via a simple tag for authentication and re-authenticate periodically. Any page or script that the user wants access to and which requires authentication MUST have an authentication PHP Program included prior to content delivery. Since we’re dealing with sessions and cookie, it mis most typical to handle authentication negotiation prior to any header content, lest your server or browser have a fit and not continue working.

While considering authentication systems using cookie and session implementation, it is wise to consider behavioral tracking, such as which pages the user visits, what their mouse moves over, and how long they spend in certain pages. This type of data may influence banner ad serving, incentives to purchase, and create a priority system for preferred customers and site users.

Just remember, session-based user authentication is little more than a check and balance system that remembers some variables in a file on the server. Once you’ve built one, you’ll feel like a pro!

Leave a Reply