If you follow the tech news you’ll often come across stories of “hackers” that have broken into secure military systems, stolen user’s login details to social networking site, extracted lists of credit card numbers from online shops, written viruses that spread across the world blocking up networks and a host of other “evil” and disruptive things. Quite often it turns out that the people doing it were young and inquisitive and instead of having evil motives just wanted to do it to see if they could.

It’s easy to look at these people with scorn and say they should channel their computing skills more wisely, but I never think that because I know exactly where they’re coming from.

I’ve managed to make a career writing software for a living. I’m fortunate in that the products I’ve built are, at any one time, in the hands of hundreds of thousands of people. I pride myself on my software craftsmanship – making phenomenal attention to detail my minimum requirement. I’m pathologically obsessed with details and building the best and most robust products I can while balancing the fact that I can’t spend an eternity polishing and improving – ultimately I have to get what I build in to the hands of people. And you know what? I may not be the smartest guy, the most talented developer or the most creative soul, but I’m pretty good at getting it done – shipping quality software.

While my University degree did cover a bit of software engineering, everything I’ve learned I learned by working with great people and having an inquisitive mind with a thirst for knowledge and self-improvement. However I had to start somewhere.

Back when I attended University it was the early days of the internet and there was a networked computer system that all students had access to. You logged on from any of the desktop computers and could access a variety of systems. I can’t remember what any of these systems were but I can remember the login system. You typed something like ‘login’ and hit a screen that asked for your user name and your password. Then you were in.

It struck me that it wasn’t very secure. If you walked up to a computer that was already showing you the login screen, how would you know it really was the login screen? So I decided to write a small piece of software that looked exactly the same, but when a user put their details in it would store them to a file, tell them they’d entered invalid login details and exit. They’d assume they’d mis-typed their password, login again and success!

Anyway, I wrote my little program, copied it onto a few machines when nobody was looking and ran it on each one so that as I walked away, anybody sitting down would think it was left at the login page. I returned a day or so later and sure enough, on each machine I’d have a look at the hard drive and my password file would have a user name and password for a real user. I tried one out, it worked, then I logged out.

To be clear, my motives had nothing to do with stealing passwords or logging into other people’s accounts. My concern was that the login system was insecure and I wanted to prove it in the best way possible – with real users. Clearly I was ahead of my time in terms of usability testing principles! I wanted to prove that the system was easy to hijack and, once I confirmed that to myself I deleted the programs and all the password files. I was much more interested in how I’d solve the problem to make the login system more secure than using login details for mischief.

I found it interesting that when Windows NT came along you had to hit Ctrl+Alt+Del to bring up the login dialog (see right). Since that key sequence couldn’t be hijacked on Windows you could guarantee when you pressed it that nobody was running a malicious login screen. Most people didn’t realise this fact but I did following on from my investigations of the network login page while I was a student. I realised then that the people in Microsoft who came up with that solution clearly thought the same way I did. And now I know they do since my career has been doing the same thing they do – building software.

It turns out that to write robust software you need to think about every possible thing that could go wrong because if you have more than 1-2 users, everything that possibly could go wrong absolutely will go wrong at one time or another. The most consistent difference between good developers and mediocre ones is that the latter always code for the ideal situation – it never occurs to them that the user’s network connection might fail, their system might run out of memory, they might delete some files out from under you, that a service you’re using might fall over or that when they query for some data, nothing may come back, etc. Good people look at something and instinctively think “what if X goes wrong?” and try to think through all the edge cases they can. That same attitude is what made me look at the flaws in my University network login system and think about how it could be made more secure.

I’m definitely not the only software developer who’s done questionable things with software in their youth in the name of curiosity or inquisitiveness. Still, I never got caught because I learned to keep my mouth shut. Until today. So let’s just keep this a secret between you and me dear reader! 😉