Introducing the Web FOB

I have been toying around with the concept of a web fob. The concept is the same as a key fob, only it would be entirely web based. The primary benefit of this would be that you wouldn’t have to carry around a hardware security token in order to gain access to secure systems.

Here’s how it would work:

1. The user would navigate to an undisclosed site and log in, at which time a security token would be generated.
The user would know, most likely through site/network administrators, that they must go to another location to gather the security token. They would navigate to this undisclosed web site, enter their authentication information, and would be handed a token. This token could be a series of digits, a phrase, or even a file that the user downloads. The possibilities are really only limited by the imagination. The ways this token could be generated are numerous and are already a well solved problem with key fobs. The technique would likely be the same or very similar, only web based. The key to this would be in maintaining secrecy in how the security tokens are generated, meaning the processing would need to be done server side.

2. A user would attempt to gain access to the secure system and would be prompted for a security token to proceed.
This could be a website, VPN, or any other system. The only basic criteria is that authentication must include something more than a simple user name and password. The user would be greeted with the login page for the site which would display fields asking for username, password, whatever else is important, and the security token. This page would have no indication of where the security token should come from.

webfob.png

3. The token would be input into the site, along with login credentials.
Self explanatory.

4. The application would authenticate the token.
The application would either know how to authenticate the security token itself (4a) or would have a server side service that exposed a validation routine from the servers generating the security token (4b).

5. The user is granted access.
Assuming successful authentication, of course.

I know enough about security to ride the edge of chaos and mostly get away with it but by no means consider myself a guru. The main problem I see with this lies in the maintenance of the security token site and keeping it secure. So to all you security gurus: what do you think of this concept? Is it secure? Is there a benefit? Is it already being done somewhere (I couldn’t find one)?


Grails Bug?

I just spent a couple hours trying to figure out why my Grails views wouldn’t match up with my domain.

This started out when I decided that I wanted to simplify my domain model and remove an item, DependencyVersion, from the middle of the hierarchy. This required the removal of the domain object and the update of higher and lower levels to fill in the gap. I am still in the early phases and haven’t started customizing my views much so the easiest thing to do (for me at least since I am a newbie to Grails – there may be a better way – speak up gurus) was to blow away the domain object, the test object, all the controllers, and all the views. I then ran my script, that simply called “grails generate-all X” for each domain object in my project, and generated new views.  I then started my server, only to be greeted by a message trickling up from Hibernate regarding the DependencyVersion class being missing but being used in an association.

My domain no longer had this class. I could even do a text search on the entire project for “DependencyVersion” and get no results. I tried everything I could think of – I won’t list it all here – but finally found out that the actual bug was resulting from grails caching the build and not updating it properly. When you run “grails generate-all X” it builds the domain classes and places them in the Documents and Settings folder. In my case, this resulted in my project being built here: C:\Documents and Settings\jmcdonald\.grails\1.0-RC4\projects.

I blew this folder away, ran my script again, and Voila!, it worked.  So am I missing something or is this a bug in Grails? I am very new to Grails and am thinking there is probably an explanation…


Method Names

Quick, what does this method do:

isSupressMultiLanguage()

If you guessed that it determines if multi-language is turned on or off you’d be correct.

Quick, what does this method do:

isMultiLanguageSupressed()

If you guessed that it is does the same thing, you’d be correct.

The point of this is that each is readable. One may flow off the tongue slightly easier than the other, however both are perfectly legitimate verbiages for the underlying flag. Both point directly to the intent of the method and give a clear picture of what its purpose is.

So what is the opportunity cost? Zero. From a development standpoint it is pretty clear that these mean the same thing and a developer can get a feel for what each method does at a glance. As long as a developer can tell what a method does from just the name, the actual naming of the method is just a matter of personal preference.