Many beginning PHP programmers set out to build a website that features a user login system but are unaware of the awaiting pitfalls. Below is a step-by-step guide through the necessary components of both a user authentication system and a user authorization system. The former is about determining whether users are who they say they are, while the latter is concerned with whether or not users are allowed to do what they are trying to do (e.g. gain access to a particular page, or execute a particular query).
||It is recommended that readers integrate the concepts outlined below into their scripts, and not simply cut and paste the code examples. Security of a login system depends on trust of the individual developing the software. Since anyone can edit these pages, including those with malicious intent, you should not trust the code examples.|
There are two parts to the authentication process:
The code given below may need adjustment depending on the architecture of your scripts, whether object-oriented or procedural, having a single entry-point into your code or a dozen scripts each called separately. However the components of a login system are executed, their fundamentals are the same. Similarly, when a 'database' is referred to, it does not necessarily mean MySQL or any other RDBMS; user information could be stored in flat files, on an LDAP server, or in some other way.
This is the simplest part of the system, and the easiest place to start. Put simply: an HTML form is presented to the user, the user enters his credentials, the form contents are submitted to the next part of the login system for processing.
The user's credentials are generally a username and password, although others are possible (such as a nonce from a hardware token-generator). Many sites are now using the user's email address rather than a username. The advantages of this are that the e-mail addresses will be unique to one user, and it allows people to have consistent usernames since users with common usernames may not be able to get the same username everywhere they register.
The data from the login form can be submitted to whatever script is to handle the authentication and login process, and it is in this script that the real business of logging-in takes place.
We don't need worry about checking inputs when logging in as much as when creating or changing the account since we're just matching what's entered in with what's in the database. Anything that is illegal (such as an e-mail address without an @ sign) will simply not have a match and the login will fail. All user-submitted data will be safely escaped when it's passed to the database so we don't, at this point, need to worry about SQL injection attacks and there is no security benefit to be gained from limiting the length or form of the username or password.
The login processing script itself needs to do a number of things. Firstly, it initiates a session (and this will often actually form part of the 'per-request authentication', as described below). Secondly, it queries the database for a matching user; if there is none then the login attempt has failed and the user is returned to the login form. Lastly (and assuming the user does exist), their identifier (username or email address) is saved as a session variable.
The script can now display a welcome message, and the authentication will stay with the user so he doesn't have to login every single time he loads a page. Let us now look at how to do that.
The users authenticity must be verified upon each HTTP request (i.e. for a page, image, or whatever). This is ostensibly as simple as seeing whether the relevant session variable is set:
This is sufficient in many ways, but it is vulnerable to a number of attacks. It relies utterly upon the session being tied to the right user. This is not a good thing, because sessions can be hijacked (the session key can be stolen by a third party) or fixed (a third party can force a user to use a session key that the third party knows). Read the sessions page of this Study Guide for more information about this and how to avoid it.
$_SESSION['fingerprint'] variables will also need to be set at the initial log in point (where the login form was processed) if they are to be used; simply insert the following lines above where the
email_address variable is set:
One thing to remember when using browser fingerprints, however, is that, while they do add some security to your application, they are not a catchall by any means. Many ISPs offer Dynamic IP addresses, which are IP address that change at certain intervals. If this were to happen while a user is browsing your page, he would be kicked out of his account. Also, the code snippet that checks to make sure the browser is the same, can be modified via Firefox extensions that modify the headers while requesting the page.
And that is how a secure user-authentication system is implemented in PHP5! There are a number of points that have been glossed over in the information above, and some that have been left out completely (e.g. how to only start a session when necessary). If you are implementing your own user login system and are trying to follow the advice given here, there are sure to be things that you will figure out as you go and will wish were explained here, so please be bold and edit this page to add anything that you feel is missing.
|If you think something needs to be changed, don't hesitate! Study Guides is a wiki which means that everybody (including you) can edit any page by clicking edit this page. You don't even have to log in! Newcomers are always welcome to Study Guides, so don't be afraid of making mistakes. If you don't know how to edit pages, check out Help:Editing or experiment in the Sandbox.|
Manage research, learning and skills at defaultLogic. Create an account using LinkedIn or facebook to manage and organize your Digital Marketing and Technology knowledge. defaultLogic works like a shopping cart for information -- helping you to save, discuss and share.