Just thought I would let everyone know that I am going camping with some friends for a few days… I will be leaving sometime tomorrow and won’t be back until Sunday.

Just in case anyone started to wonder why I stopped making any commits, that’d be why

Oh, and earlier today I gave a list of sections in the control panel which were done or still needed work, I thought I would update that list:

• System Settings – Done
• Themes – Done
• System Update – To do
• About – Done
• Errors – Done
• Add Member – Done
• Manage Members - Almost done, I want to make a few tweaks Done
• Member Settings – Done
• Member Permissions – To do Done
• Add Plugin – To do Done
• Manage Plugins – To do Work-In-Progress
• Plugin Settings – To do
• Authentication Tokens – To do (see below)

I just might do a bit more tomorrow if I have time, but it is unlikely. Even once I have completed the control panel, we won’t immediately release SnowCMS 2.0 beta because I have a few things on the main part of the system (registration, logging in, profile editing and password resets) I need to do. I know that sounds like a lot of other work, but its not. A couple things still need to be updated to use the new Form class which won’t take much and I also just want to make sure registration, activation, resending activation emails and resetting passwords works properly — so just testing.

But I guess there is one other thing I should add to the list *adds to list above* which is authentication tokens.

If you aren’t sure what I mean, I will explain… Currently when a user logs in to their account a cookie is saved containing their log in information — pretty standard. This cookie contains two things: the users id (member_id) and their hashed password. I have decided (and this was on the road map for awhile now for beta, anyways), along with others, that this is old, outdated and insecure.

With this planned method of keeping a user logged in a token (hence ‘authentication token’) is assigned upon each log in. This token is a randomly generated string of characters (a, b, c, 1, 2, 3, !, @, #, and all that stuff) which is then saved into the database of authentication tokens which will also contain the owner of the token (the member_id), along with other information. This authentication token is in no way related to a users password which means when logged in the users password is not being transmitted in any shape or form after logging in (we will have a secure log in plugin which will help prevent password sniffing at all, whether or not you are browsing with HTTPS).

There is another benefit to these tokens, because as I said there is other information stored along with these authentication tokens. This includes such things as the time at which the token was assigned, when the token is set to expire, the IP from which this token was assigned, and even the browsers user agent.

The expiration time would be set by that drop-down box that is currently shown when logging in. The token will expire and no longer be valid after the time at which it expires. Sure, a cookie does that, but a cookies expiration date could certainly be extended, so this adds a strict time limit.

The owner of the website would be allowed to impose other restrictions on tokens as well, such as requiring that use of the token come from the same IP and browser.

Also, users will be able to go into their profile and view current tokens which are still valid, which they may revoke if they so please. Just in case you forget to log out of a friends computer — or something like that . Kind of like what Facebook currently does.

While this idea certainly does have its limits (there is nothing to stop key logging software from getting your password), it certainly has its benefits… and a little extra security never hurt anyone, right? Right..?