Wednesday, April 09, 2008

Downgrade the password...

So it has been quite a while since the last post (and I promise to get back into the EC2 soon). I had to quickly post this because it really got to me...

I am on vacation for the next few days and about a 1/2 day into the first day the voice mail light goes on the phone; it is work. It is a message from one of team members stating that the password I set to authenticate access for a 3rd party to our PCI web services will not work because it has a quote in it and they need to know what might break if they change it. I would have been opposed to changing the password just because the code couldn't properly handle a 'special' character in the password. The team did the right thing though, for the short term, and changed the password so that we were not blocking access to the services which was having a serious impact on the customer (the WS is still authenticating so that is good).

I know that the application calling the service is written in .Net (probably VB.net) and that they were able to quickly change the password, so I'm thinking a web or app.config. So why didn't they just encode the 'special' characters in the same .config? I'm not sure and will ask about it when I get back next week. This seems like the solution but I'm not a .net coder.

This entire situation is ironic to me. The IT team at my work has been doing some great work over the last year or so on securing our applications, especially from a PCI perspective. And then we get hit by an application that is brand new (written over the last month or so) which can't handle a password with 'special' characters.

Is this a problem with the tools? I don't think so.

Is this a problem with the coder not knowing how to do this? Doubtful too, they probably know how to encode this just fine.

What is the problem then? In my opinion this is a typical mistake that is often made. Code for what _you_ know. Too often are coding decisions based on how the developer lives and works right now and not for how the system is really going to be used or better yet, for how it may be used in the future. Being a programmer takes a certain degree of fortune telling. We should try to think about the scenarios that are down the road for this application and what it may come up against. This may be a stretch for just a password character issue but I think it probably hints at what problems may be around the bend.

Monday, February 11, 2008

Starting out with Amazon EC2 (Prelude)

This is the first in a series of posts which will cover my experiences with the Amazon EC2 (Elastic Compute Cloud) services. I had first read about EC2 a few months back and tagged in my del.icio.us account but for some reason never visited it again (I can tell why: too busy working on the wrong things, i.e. legacy application support). Then, I attended the February Columbus Ruby Brigade meeting and the presentation was on Amazon Services (EC2, S3, etc.).

Some background info: I have recently been working on a Data Center proposal for work which will hopefully move most of our Internet presence into a full-on ultra-redundant Data Center. But the presentation of the Amazon EC2 services has me thinking; why do I need to have physical servers in anyone's Data Center? Could I put together a plan which minimized the amount of real iron that we have to buy, maintain, and find a home for and replace most of that 'stuff' with computing in the cloud?

Well I'm going to try... It may or may not work out for this specific project but I aim to make the experience fun and definitely educational for me (and hopefully for you too).

Please check back in, as I work my way through the EC2 experience.