
The first method was a code book; a simple one but effective and offering physical protection, this method is achieved by simply choosing a new chapter from any given book each month, taking the first however many chars you would like and selecting the first letter or the last letter or a combination to form a password. This method is pretty secure but does require a book (or I suppose an electronic version).
The second was a password map. This is the age old method of creating a A = r , B = p method using symbols and case matching to achieve a secure password. Then you just need to generate a plain text word (such as the month name, lunar cycle etc) and then convert it using the map. Again effective because it requires 2 stage authentication (access to the map and knowing the key word).
Both these methods are very physical. They work, but require either the book, or the map and to remember the chapter and the key word respectively. In essence, not ergonomic to the user, in the brain-workout department!
Many services in the US now use physical token authentication. I've seen services similar in the UK, but only for higher security apps. Physical token uses a simple device, shaped like a usb key or card in some cases. These devices generate seemingly random codes to use at authentication point along with a a password. The devices do not communicate, but rather hold a complex mathematical calculation to generate the code based on date, which the authenticating system also holds.
So far I've seen variations of this used by eBay/PayPal and brokerage services in the States, along with my bank in the UK. The UK version is calculator size and requires you to enter a challenge code before the auth code is released, increasing the level off security even more so.
So I've been dreaming of using this with my wiki for some time. MediaWiki is fairly extensible and I've known there was an addon that should support token authentication. You can of course go through the rigmarole of setting up your own authentication service, but this requires server software installed on a non-Linux client and then a PAM authenticator installed on the local server. Its a little long winded and resource hungry but is secure.
The other method is achieved by using a proxy service like Verisign's PIP. This allows tokens to be linked to the OpenID system (kind of a universal username and password). By using this system I was able to link the Wiki in with OpenID which in turn linked to the token.
The best part about this was that I was able to use my PayPal key and register it with PIP, saving me the time and cost of an additional token. This cross linking is now always possible, but I imagine that in the future it will be.
So all in all a very successful project, as my Wiki is now protected by secure token authentication. The only slight issue I have is the "forgot your token?" link which allows a one-time access code to be sent via email. This seems a little redundant to me, and dangerous if you are in the habit (as many of us are) of leaving yourself signed in. All in all though, pretty darn secure.

0 comments:
Post a Comment