Wow, I haven't added to this blog in over a month. The ironic thing is that the winter time is usually the slowest time for a developer who works for the government. Especially where I work. The organization that I work for are re-organizing themselves, and have no time to look at proposals or statements of work. So, we just sit and wait for something exciting to happen. Since we are on a fixed price contract, we still get paid.
Although, times haven't been that slow for me at work, and home. My wife, kids, and myself have all been sick. The relatives came in from out of state. And the holiday season in general makes simple tasks a mad house. But enough of this non-technical stuff. Anything interesting?
Well, yeah, kind of. I was assigned a task to look into new security requirements for many of our apps. These requirements were signed by President Bush about 2 years ago. Some are simple, like session timeouts must be set at 30 minutes, and tracking all access to "Personally Identifiable Data" (aka Social Security Numbers). Some were a little more complex, like enforcing 2-factor authentication. Since many of our apps deal with secure data, and because of the whole VA Laptop thing that happened last summer. My group needed to do something, fast. For all new apps, the security requirements have already been put in place, but the older apps needed to be updated.
The interesting part was working on a solution for enforcing 2-factor authentication. Typically, a website has 1-factor authentication, a password to proove that the user is valid. 2-factor authentication is a way of not only proving the user is valid with something that they know, but to request something that they have as well. Things like smart cards, biometrics, and security tokens are just a couple ways to help prove that you are who you say you are. Our government client decided on using security tokens to solve this problem, in the short term, at least.
The security token works on the concept of this little device that displays a 6 digit number, that changed every minute. A user would enter a pin and the 6 digit pass code to prove their identity. However, these little devices are about $70 a pop. Considering that hundreds to thousands of people use our systems, that can get costly. Well, it turns out that most people who use the systems, don't need to have access to the secure data anyway, they only need access to the non-secure data on the sites. We have user roles to enforce who can see what. However, there can be 2 people on the same role who can see the same data, but only one needs to see the secure data. We wanted a simple way of hiding the secure data, without recreating the users into new roles, and causing as little modification to the code as possible. Therefore, only a small fraction of people will need the tokens.
All of our security and user authentication code was generated through ColdFusion/Java and an Oracle back end. The use of the ISAPI dll that came with the secure tokens wasn't useful for us, and I couldn't find anything on the net about this type of implementation. So I had to design our own way of doing this. I will discuss my solution in my next post. If anyone has run though this situation before, I would love to hear how you handled it.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment