When I started seeing spam messages posted to the new column annotation system, I knew I would have to create some sort of user authentication system that helps weed out the losers. I'm the type that would rather write an entire library myself than try to learn something like PHPLib or other similar libraries.

The library needed to handle registration, confirmation emails, account updates (passwords, emails) among other things. It also needed to be secure while not creating a burden on my overloaded database.

So the new system needed to rely on cookies while not being totally exploitable. It was an interesting dilemma. I knew I couldn't simply set a user_name cookie when they logged in (the user name cookie is easy to spoof). I also knew I didn't want to set a simple hash and have to confirm that hash against my database.

The solution was to set both. A user_name cookie is set, along with a hash. The hash is an md5() hash of the user_name as well as a super-secret variable that only PHPBuilder knows. Since md5() is a one-way hash and is, for all intents and purposes, going to secure practically any website, but should not be taken to be "uncrackable"*. I could safely create a hash of the email, which is a known variable, plus the secret variable. It's kind of a public-key/private-key kind of system.

The interesting thing about this system is that it could scale up almost infinitely. Since the hard work of this system is done by md5() on the web server, additional servers can be dropped in incrementally to handle the load. The same is not true of an auth system that hammers a database - the database itself eventually becomes the bottleneck.

* This is a correction requested by the author. Please see comments below for clarification.