Throughout my time developing login's I have never made a real AJAX login that covers all my security concerns. Now a login/registration system I consider the bread and butter of any web developer, and AJAX login tutorials are all over the internet. Yet when it came to making my own AJAX login I found myself worried about how secure it really was.
The basics of a dynamic login system are as follows:
- Main login page
- Another page to handle incoming requests and respond with XML or JSON
- Your collection of logins, normally a database
This is all well and good however there are a few more complicated issues for what I wanted to achieve.
These where my objectives:
- Lightbox that will prompt the user for login details, this lightbox needs to be reusable from any location on the website.
- Upon a successful login the user will be redirected to the "home page" for logged in users.
- Upon failure the lightbox will be updated with what details are missing.
This may sound very simple however I had one major issue. The successful login had to redirect the user. My problem with a redirect is I do not have the option to POST values when redirecting the user. Any values I want to push across must be done via GET. My second issue is due to the way my PHP framework was constructed I am unable to assign a session or cookie to say the user is logged in.
Another issue is the highjacking of logins. While I can do my best to encrypt the username and password of the user in the AJAX process, how can I assign them a value which links them to their account without compromising their account? A common issue often overlooked is shared computers. Using an insecure GET can result in users having their accounts abused by the history function of most browsers.
So how can you get around these issues?
A very simple solution is to use a token. Here is the plan, expand the database to hold a timestamp/datetime as well as a random 64 random character string. The idea is the first request that comes through will not only respond with a success or fail but also with the token assigned to that login.
The first POST of data will send the username and password to the waiting page, this waiting page will check the login details, if it finds a match it will update the row with the current datetime as well as updating the randomly generated token.
Now we will respond with a JSON success or failure, the failure contains the message of why it failed. The success will also respond with the token.
The redirected page will then simply look at the token and check the timestamp, once a valid record has been matched we then assign the session and deem them logged in. This extra security given by the token allows us to be more flexible.
You filthy comment whore, you love it don't you?
Lets not be forgetting to +1 it now... I am tracking your IP...