Web security 0.1

[tigrino]

I had thus silly idea to quickly throw together a website for myself to list up my motorbikes. Well, not «mine» per se, I do own only one, but the ones I have ridden over the years and have an opinion about. Since I like to do things «my way», I searched for a rapid development framework instead of heading over to a motorcycle website. Silly me. But that’s besides the point.

I looked at the CakePHP framework and it appears a solid piece of engineering I could be happy with. The only problem is that I have been trying to get the user registration and login set up for the better part of two months now (I have a day job too).

There are plugins for doing user management and complete login and registration libraries but all that I looked at share one thing in common (and with CakePHP itself, too): they are written with a frightening disregard for security. Every single one of them. So much for Open Source and crowd-sourcing. I would not use any of them to manage my website. Period.

So, I embarked on a quest to write my own plugin for CakePHP that would demonstrate what you can do with the user sessions security if you really put your mind to it. I have a first draft running now, very simple actions only but it works. So I am confident that once I get my head around the concept of plugins in CakePHP I will be able to provide a plugin with far better security for user sessions.

Some points that come to mind when thinking what has to be done vs. what is usually done:

1. The user identifier is usually predictable, allowing often for a user listing. It is either an auto-increment in the database, or a UUID. Neither is unpredictable. A random 64-bit value will be far better, even when the random generator is not all that great.
2. The user name is the primary identification. This is, in my personal opinion, passe. The user ID is the e-mail address.
3. The confirmation links (registration, password change) are silly MD5 hashes of the current time. I think, again, a 64-128 bit random will be so much better.
4. Some send out a new password to the user in an e-mail. Instead of a random token. That is simply not to be done.
5. The «remember me» cookie is usually implemented by sending a user name and a password hash to the user browser in a cookie. That is plain silly too. This, again, has to be a random token stored in your database and given to the user.

That’s what I come up with just off the top of my head. But I think these are already sufficient to ditch the current system and build something better. So I am on it ;)

Оригинал: https://tigr.net/2012/06/28/web-security-0-1/