Hackers are getting smarter and smarter all the time. Not so much we can do about that. However, we do have one advantage - authentication technology is improving all the time as well, if you choose to take advantage of it. That is one reason why I promote the use of third party tools for authentication whenever I can. They have done it before, they know the pitfalls, and they know how to avoid them.
The solution that I find the best is a product called OpenAM. Originally released as OpenSSO under Sun, the product was spun off from OpenSSO after Oracle bought Sun and announced they would no longer be supporting OpenSSO. Forgerock now controls OpenAM, and it is still pushing the boundaries of secure web access. On top of that, it is relatively easy to set up and use, and has a whole lot of other benefits besides secure authentication.The way OpenAM works is that it is actually a standalone server application. It has a nice built in web interface for configuring all of the authentication and authorization rules for all of your websites. It basically sits out there all by itself, waiting to direct traffic coming into your server.
Now here is the fun part. OpenAM also has what they call Agents. An Agent is a plug in of sorts that you install on your web server. They have agents for most of the major versions of most of the web servers out there. The Agent sits on your server, and listens to all of your incoming traffic. It also has a list of URLs that it needs to be aware of. This may be a blacklist or a whitelist, depending on how you set it up, but the long and short of it is this - the Agent knows, from the OpenAM server, what URL accesses need to be authenticated.
If a request comes in for a URL that the Agent knows it needs to protect against, it checks for a secure cookie from the OpenAM server. If the requester does not have that cookie (as is the case for first time requests), it sends a redirect over to the OpenAM server. It is kind of like a cop guarding a building, and if you don't have ID he sends you to the courthouse to get some.
Once the user is redirected to the OpenAM server, they see a login page there. Once they provide satisfactory credentials, the OpenAM server sends them back to where they were heading in the first place. The server acts like the judge, who has given his OK for you to go into the building. Having done that, he sends you on back to the cop.
Once the user gets back to your web server, the Agent sees that the OpenAM cookie now exists. Wanting to verify that it is a good cookie, being the good cop he is, he gives the judge a quick call. The Agent connects directly with the OpenAM server, and asks if the cookie is still a valid one. Assuming an all clear from the server, the Agent sends the request on to the final destination.
And that is the gist of it. All of the authentication is handled by much more experienced folk than you or I, and everybody is happy. As an added benefit, this is also what is known as a single sign on solution. That cookie that the user receives from the server? It sticks around in their browser as long as it is open. That means that the user can go to any web page on any server protected by the OpenAM server, and never have to log in again.
In addition, there are other benefits such as complex authorization rules for whol does or does not have permission to access certain parts of your site, as well as built in support for being a SAML2 Identity Provider. And to top all that off, all of these benefits are free. Free makes everything taste better.
I plan on following this post up with more specifics on how to get OpenAM set up and running, so stay tuned.
