Damian Brady’s Blog

In a previous post, I talked about the limitations with CAPTCHA systems and proposed a partially-automated turing test to keep non-humans out.

I had a few discussions about this with a friend and he was more interested in the CG Kittens idea I very briefly alluded to in the main text. To summarise, the idea was that if the kittens in KittenAuth were 3D models rendered on the fly, you’d get an essentially unlimited number of images.

Well someone has gone and done something very similar. On a small site called SpamFizzle, there’s a description of a 3D CAPTCHA design that renders simple objects and asks the user questions about them. It looks like a great idea to me. It could require some fine-tuning, but I think the premise is sound.

I’d love to credit the author some more, but there are no details on that page. I presume it’s the same author as the only other page on the site, Michael G. Kaplan.

Regardless, it’s a great idea and worth a read if you’re interested.

The Queensland Government recently introduced the Go card to provide a single intelligent ticketing mechanism for (almost) all public transport in South East Queensland.

The technology was developed by Cubic Transportation Systems and similar cards are in use all over the world.  The idea is when you get onto a bus or a train or anything, you touch your Go card to the sensor.  When you get off, you touch it again and the appropriate amount of money gets debited from your card balance.  Presuming it works, it’s a sensible system in my opinion.

Despite catching a bus to (not from) work nearly every working day, I had originally avoided the new system for a few reasons.  The main one was that it provided no financial benefit to me.  There’s a refundable deposit that’s payable when you buy a card, and the cost of an individual one-way ticket was the same whether you used the card or paid cash on the bus.  Discounts only came when you used it more than 6 times in a week.  I very, very rarely travel by bus more than half a dozen times a week.  In early August however, the fares will come down for the Go card only.  This makes it more attractive, so I went to purchase one.

The TransLink website provides an online web ticketing service that lets you purchase a card online.  Presumably they send it out to you but I didn’t get that far because frankly, I was too scared.  Let me show you.

After a couple of short screens asking you about the type of card you want, you come across this screen (click to enlarge):

Notice the “Billing Account Question” at the bottom.  There’s no more information on what this is for, but I presume it’s some kind of verification question you have to answer in order to make payments or maybe changes to your billing details.  The default question is, “What is my name?”.  That’s probably the worst security question I’ve ever heard! Ok, I’m generous, so I’ll give them the benefit of the doubt here and assume that this isn’t used for anything important.  You can change it anyway, and if you’re sensible, you probably will.

Let’s look at the next screen:

The first thing I noticed was that there was another “Cardholder Question”.  Is this different from the other one?  Again, there’s no help available to tell you what it’s for.  At least the question is slightly more difficult to guess this time.  I wasn’t terribly concerned at this point, so I continued.

Here’s the next screen:

Now I’m quite concerned.  Firstly, it appears that despite this being a Queensland Government website, I’m suddenly being charged in pounds.  On one of the first screens, I was told that the charge was $5 so I could probably assume that they just got the currency symbol wrong, but this is a big deal.  What if I am going to end up paying the equivalent of just over $10? I had a look at the address bar to make sure I was still in the right place, and yes, it’s an Australian domain.  I’m growing more and more reluctant to sign up to this thing.  Of course by this stage, I’ve already given them my credit card details, and who knows whether they’ve been stored.

So next, I clicked on the terms and conditions link at the bottom of the page.  Here’s what the pop-up window said:

So that’s it.  I’m done.  No way I’m going to buy online using a credit card from a site with that many problems. The other thing that the terms and conditions error showed me was that they appear to be using Lotus-Domino version 4.6.7a.  The current stable version is version 8.  And does that “a” indicate an alpha version?  The Wikipedia page on Lotus Domino doesn’t even recognise the software before version 5, and the page on Lotus Notes suggests that version 4.6.7 was released sometime prior to 1999.  I’d hate to think what kind of exploits could be carried out on that server.  Colour me scared.

Now, I’m sure I could have continued on my merry way, bought the card, and everything would have worked out fine, but I wasn’t convinced that the transaction would work or even that my information was safe.  SSL or no, the currency problems and the information gathered from that error page just scare me too much.

To be honest, I’m not sure I’m comfortable buying the card at all any more.  The cards have to be registered, so I assume I have to give them some kind of personal information.  With web software that old, I simply can’t trust that it’s safe.

I certainly hope they sort all this out soon if they plan to decommission their other ticketing options.

Damo

I want to preface this post with a couple of disclaimers.  When I talk about passwords in this post, I’m talking about the ones that matter.  I’m talking about your Windows Login password or your Internet Banking password, not the password you use for Facebook or Digg. Let’s be honest, nobody really cares enough about those accounts enough to break into them.  Also, I’m not going to address how the password is stored or the physical security of the resources.  Ideally, there’d be more than just a password.  However, for the purposes of this post, I’m assuming that the password is the only way in.

Now to my blunt opinion.  Most password policies are bad.  They fail spectacularly to solve the problem they’re meant to solve.

Usually, password policies (particularly in workplaces or universities) enforce a few rules.  Some of these rules are useful and some aren’t.  So called “standards” or “industry norms” are followed, but there seems to be little thought put into the password policy.

A large number of password policies I’ve come across follow these two rules:

• The password must be technically complex, usually judged by a basic algorithm; and
• The password must be changed frequently.

While they both seem sensible on the surface, I ask you to actually look at them in terms of the problem they’re supposed to solve.  It’s probably not much of a spoiler, but I’ll let you know that I have a problem with both of these rules.  They don’t effectively solve the problem they’re meant to solve.

First, let’s look at the problem a password is meant to solve.  Obviously, a password is meant to prevent unauthorised access to a particular resource; usually a computer, a network, or some software.  The assumption is that unauthorised access is bad and must be prevented, and don’t worry, I’m not going to argue with that.

So, looking at the first password policy rule listed above, does having a technically complex password solve the problem of unauthorised access?

The problem is that true complexity is very difficult to judge with software.  If a judgement is made on a character-by-character basis, it is essentially useless.  A password like Pa$$w0rD for example, will almost always be judged as technically complex, but would be relatively easy for a sensible password cracking algorithm to break.  It’s not enough to assume a password is good because it meets your easily-testable rules.  I submit that the only good way to test whether a password is secure is to try your hardest to break it.

Enforcing a rule that makes sure a person has a certain number of characters and that they belong to several different character groups (uppercase, lowercase, numbers, symbols) means that a brute-force attack would probably be infeasible.  But as a software developer, if I really wanted to find someone’s password, there’s no way I’d be doing a blind brute-force attack.  I’d start with a dictionary of common words and I’d add things like the person’s date of birth, their partner’s name, their children’s names, their pets’ names – essentially any personal information that I could find.  I’d write some code to try things in a sensible way using these words prefixed or suffixed with numbers or other characters.  I’d try changing the letter O to the digit 0, i to 1, a to @.  Of course in the end, I’d probably just find a tool that did all this for me, but I wouldn’t just go trying random characters.

So does the first rule meet our goals?  Does enforcing 8 characters including three different groups guarantee a good password?  No it doesn’t.  You can set a terrible password and still follow the rules.

Onto the second rule – regularly changing the password.  Let me first say that this is a rule I hate.  Not only does it not meet the goal of protecting an account, it actually makes things worse when combined with the first rule.  Let me explain.

The reaction most users have when you tell them their password has to be (for example) at least 8 characters long and contain uppercase, lowercase, and numbers is not entirely positive.  It’s not always easy to think of a password that meets all of these requirements as well as the unspoken one; you have to remember it.  For obvious reasons, unless they’re instructed otherwise most people will choose something easy to remember like their surname followed by their birthday.  It meets the requirements and they can remember it.  To combat this, sensible administrators will explain how important it is that the password can’t be guessed and encourage another method of choosing a password.  They might suggest turning a sentence into a string of characters.  For example, the sentence “I’m going to try to remember this password” could become “ImG2t2RthP@ss”.  That’s a pretty good password – it meets all the rules, it looks very random, it will survive a dictionary attack, and most importantly it can be remembered.  Basically, it’s going to take a very long brute-force attack to guess.

Now, what if they know they’ll have to choose a new one to remember every month? Are they going to pick a hard password then?  I’d suggest that it’s far less likely that they’ll go through this process of turning a sentence into a password every month.  Even though it’s easier to remember than a random string of characters, it’s won’t stick instantly.  It might take them a few days before they can type it without thinking.  And if they have to do this every 30 days, it becomes that much harder to properly cement it in.

The user is thinking, “why do I have to change it?  My last password was good enough!”, and you know what?  They’re right.

The common argument is that a password should be changed frequently in case it gets compromised.  If someone discovers the password, they’ll only be able to access the system until it’s changed.  While this may be technically true, what does this really accomplish? How long does it really take for someone to do whatever they wanted to do by gaining access to your computer?  The fact is, as soon as someone else is able to access something they shouldn’t access using your password then that’s it – mission failed.  Are you really going to hang the strength of your security on the hope that the attacker won’t have enough time to do what they want to do before the password changes again?  It’s made even worse by the fact that the password is less likely to be a good one.  If I discovered that your current password is “January101182″ or “Smith111, it probably won’t take me long to work out your next one.

To summarise, a password policy like the one in the bullets above that enforces some level of technical complexity and makes the user choose another one every month fails in a couple of ways.

Firstly, enforcing technical complexity is the ultimate false sense of security.  It doesn’t force a user into choosing a good password.  In fact, combined with a rule enforcing frequent password changes, it encourages bad passwords.  Also, the warm fuzzy feeling the admin gets from knowing a password is at most 30 days old is fools gold.  The damage is done as soon as the password is discovered, and it’s more likely to be discovered with a 30 day turnaround because the password will be worse.

I know this is an essay already, but it would be unfair of me to end after attacking common practice without offering an alternative.

So here’s what I suggest:

• Passwords should be technically complex, but they must not be easy to guess; and
• Passwords should be changed at most once a year unless there’s a suspicion they’ve been compromised.

How do you achieve this?

Instruct each user to use a method like the the one suggested earlier; compressing a sentence to choose a password.  Make it hard – 10 or 12 characters in all four categories.  They won’t have to change it regularly so who cares if they take a while to remember it.  If they absolutely need to, let them write it down and keep it in their wallet until they remember it.  If they lose their wallet, then change the password.

Of course as I mentioned earlier, the only real way to test the strength of a password is to try to crack it.  So do that.  Set up a simple system that stores a hash of the person’s password, and try to break in using whatever means necessary.  In particular, look for personal information to work with.  If it’s too easy, you should be able to break in quickly, and if you do, make them change the password to something harder.

So there you have it.  My opinion on why most password policies are bad.  Sometimes you actually have to revisit the problem you’re trying to solve rather than just follow so called tried-and-true policies.

-Damo

I stumbled across Part 6 of a Programming Job Interview Challenge on the Dev102 blog and thought, “hey, I know this!” I couldn’t help responding.

So the question was, given this bit of code, what will the output be?

   1: ArrayList a = new ArrayList();

   2: ArrayList b = new ArrayList();

   3:

   4: a.Add(1);

   5: b.Add(1);

   6: a.Add(2);

   7: b.Add(2.0);

   8:

   9: Console.WriteLine((a[0] == b[0]));

  10: Console.WriteLine((a[1] == b[1]));

Ok, so I’ll break the post here in case you want to work it out for yourself, but you should really go to the original post – not least because there are five other challenges there.

Read more »

There’s no shortage of people lambasting the recording industry for keeping their business model firmly behind the times.  The ability to download music online seems to have presented the industry with a challenge it simply can’t accept.  They have a hammer that’s been serving them well for a very long time, and by god they’ll bash away at this problem even though it no longer in any way resembles a nail.

I’m not going to rehash the arguments or the history here, but needless to say, the recording industry has very firmly clung to the the premise that no matter how much money you pay, they must retain control over what you do with that music.

Enter a new business model that is doomed from the start.  Lala.com presents a model that is essentially a rental scheme.  I found out about this site via Slashdot and Michael Robertson.  Lala has a large number of songs on it (over 5 million) that you can search, listen to from start to finish once, and then add to your playlist for 10c.  Once the song is on your list, you can play it whenever you like.

Here’s the catch: you can only listen to the song via the Lala website.

Ok, that’s not entirely true, you can (sometimes) pay more money and buy the track in mp3 format, but the new business model Lala is going for is clearly listening to your 10c tracks via their website.  They get to control everything because you stream the music.  You can’t put it on any devices or burn it to CD.

So why is this doomed from the start?  To be fair, I’m sure there would be some people who would be happy to pay such a small amount of money to be able to listen to their music from any Internet-connected computer, but I’m not one of them.

I generally listen to music in several places using different devices.  In the car, I’ll listen to music on the radio, on CD, or on my iPod.  At the gym, I’ll listen to their music or my iPod.  At parties, I’ll listen to music from a stereo via an iPod, CD, or yes, a computer.  And sure, sometimes I’ll listen to music at home or at work from a computer.  The vast majority of my music-listening is done via a little plastic disk or a little portable music device.

Now, there’s some criticism of the restrictions forced upon you from online music stores like iTunes.  iTunes lets you download music, but the files contain DRM that restrict what you can do with it.  According to the website, you’re allowed to burn it to CD as many times as you like, and copy it to as many iPods as you like.  You can only put it on up to 5 computers though.  Not much of a restriction – who has more than 5 computers?

Lala on the other hand won’t let you burn to CD and won’t let you put a track on a music device, but they’ll let you play it on as many computers as you like (via their website).  For me, that means I can no longer listen to my music in the car, at the gym, or anywhere without an Internet connection.  That’s a deal-breaker for me, and I’m sure for a lot of people.

The argument is between consumers who want to be able to purchase something without strings, and record companies who want to control their rights and insist that you’re only buying a license to play the music they still own.  Launching a website that tightens control over what you can do with the music is stupid.  It’s giving people the exact opposite of what they want.  Mark my words, this idea will fail, and it will fail hard.

Update: Ars Technica, Wired, and CNet have written about this beta of Lala.com now as well.  The general feeling seems to be similar to my own – they’re unsure of the 10c streaming model.  Also, see the comments section of this post for a reply from one of Lala.com’s employees.

I found this article by Steve Yegge claiming that the Singleton pattern is stupid and evil.  I know it’s old, but I found it via reddit (which I’ve been getting into a lot more than Digg lately – probably more on that later) and despite having his blog on my feed, I hadn’t gone back that far into his archives.

I read about half of the article before I decided I’d write my own post pointing out that he’s actually attacking not the singleton pattern itself, but its use in inappropriate circumstances.  I use the pattern occasionally, and I’d like to think I use it when it should be used or at least when it’s useful.  The examples he gives throughout represent inappropriate uses for the singleton pattern, not a failure of the concept.

Then I read the rest of it, including the final note which says:

Note: I think there are some good uses for the Singleton pattern, but it’s so incredibly overused, and serves as such a convenient crutch for people who don’t understand OOP, that I figured I’d just take the stance in this article that it’s basically Evil.)

Huh.  So here I am writing a post about nothing.

If you’ve visited here before, you’ll have noticed that the template I’m using has changed.

While the old one looked good to me for a while, the more I looked at it, the more I thought it just looked too busy.  There were borders all over the place and gradients and background textures and all sorts of things.  It was too much.

So I’ve gone the minimalist approach and have chosen a template that’s very simple.  I hope you like it.  I think it makes the posts easier to read.

Damo

It’s great when software is designed and implemented with careful planning and plenty of documentation so someone can pick it up when it falls down.  Unfortunately, it’s often the case that a) You’re working on an existing project that has no documentation, or b) You’re working on an existing project that has documentation that is now out of date.

I’m doing the former right now.  The software is old.  Like 12 years old.  It has no documentation.  It has duplicated code, code where it shouldn’t be, hard-coded values, code that does the wrong thing before being corrected by other code.  Think of an anti-pattern and it’s in there.

The application is being phased out, but it must be supported until it’s completely gone.  It’s also in an environment where changes are inevitable and legally mandated so there’s no chance of a complete code-freeze.  The original programmers are long gone.  It’s not fun to work with.

Now don’t get me wrong.  I don’t go in and make changes that just add to the spaghetti – I refactor when it’s practical.  If I’m changing some code that’s repeated in three places, I’ll pull it out into its own method.  If there are hard-coded values that could change, I’ll set them up so they’re configurable.  In short, I’ll do some cleanup, but I’m not going to do it all.  Refactoring everything would mean nearly rewriting the thing from scratch, and that’s been done (hence the phase out).

So what about documentation?  Writing detailed UML for this software is just not practical.  For one thing, it’d be obscenely hard to do, but more important is the fact that this program is unlikely to be in use in 12 months time.  Priority doesn’t go to documenting legacy software.  The fact of the matter is that it’s just not worth the time and effort to pull the thing apart to work out how every little piece ticks.

So I’ve come up with my own alternative.  I call it Post-traumatic Documentation.

I’ve set up a document that I’ve titled the Application Body of Knowledge.  Every time I dive in to make a change or fix a bug, I’ll absorb a whole lot of information about how the application fits together.  There are basic things like which files do what, but most of the important stuff is in the details.  I might spend half an hour working out that some assignments in method A get overridden in certain cases when method B is called, or that a class called ABC actually provides functionality for DEF and perhaps doesn’t get called at all.  I learn these things the hard way and I make notes as I go.

Whenever I finish one of these traumatic quests to change something small, I go through my notes and add anything of interest to my Application Body of Knowledge.  There’s a section dealing with the overall architecture of the application, one for each of the main modules, one for deployment, and one for general notes.  It’s deliberately heavy on keywords and jargon to facilitate searching.

This document is obviously far from complete, but it is immensely helpful to me when I next have to make a change, and it’ll be even more helpful to the guy who takes the reigns from me when I get hit by that programmer-killing bus.

Damo

Let me preface this post by saying that I haven’t played it. In fact I don’t even own a console that is able to play it. I’ve never even seen anyone play it, and I’ve watched maybe one trailer about halfway through.

So why am I writing about GTA IV having had no hands-on experience and no exposure?

Well, I’ve been absolutely inundated by the flood of reports, articles, blog posts, editorials and reviews about GTA IV. I spend a lot of time on the web and I watch my share of TV and listen to the radio, so I’m fairly up to date with what’s being talked about online and in the media.

So here’s what I’m aware of so far. Despite the massive success and constant positive reviews of the recently-released Ironman movie, its revenue is likely to pale in comparison to sales of the latest Grand Theft Auto game. The media is jumping all over reports that Hollywood is (once again) scared that computer games are going to seriously eat into their profits.

It’s been said before, and it’s a fairly legitimate fear. It’s worth noting though, that movies and computer games compete in the entertainment market only indirectly. Sure, there’s some overlap, but $100 million in movie revenue will not be replaced directly with $100 million in computer game sales. There is room for both. Motion picture industry revenues certainly haven’t experienced the same massive growth as the computer game industry, but there haven’t been many huge changes in movies in the last few years. Computer games on the other hand have improved out of sight in a short number of years. There are still brand new technical advancements being made (think Wii) while movies now have slightly better special effects than a few years ago. It’s an unfair fight and this result isn’t really surprising.

Anyway, it seems that this game is a very big deal. It’s apparently got a very complex storyline; one that competes with big plot-based Hollywood movies. The big difference is that being as interactive and immersive as the GTA games are, it’s infinitely more interesting and longer-lasting than a movie. There’s little doubt that the $100 million it cost to make will be well worth it. The real question will be whether the other games companies will continue to pump out the same games with better graphics, or whether they’ll go the way of Rockstar and start releasing games that are more like fully interactive movies.

Damo

Every few months, my bank card decides it’s not going to work.  Usually generic ATMs or those of other banks refuse to accept it, but this time it was an ATM belonging to the bank I’m with.  Once again, I walked inside the branch and arranged for another card to be sent to me.

In addition to ordering me another card, the customer service rep offered to link my Visa card to my savings account so I could use it to withdraw money from my main account.  I’ve never had problems with the Visa, so this may be a more permanent solution.  Regardless, I needed to choose a new PIN for this to work.

Here’s where it gets interesting.  I was asked to type in a new four-digit PIN with various obvious restrictions such as no birth dates or other important dates, but also with no consecutive double digits.  My initial reaction was that it was an unusual requirement (given that I’ve had PINs with double digits assigned to me by the same bank in the past), but I didn’t think much of it.  That was my initial reaction.  As I considered it more, I thought, wouldn’t this would have the opposite of the desired effect?

Now my probability mathematics is a little rusty, but here goes.  There are 10,000 possible four digit PINs.  If a truly random PIN is chosen, the probability of guessing it on the first try is one in ten thousand.  Given you usually only get three tries before the machine swallows your card, the odds aren’t good.  If you let people choose their own PIN with no restrictions, it could be a little easier – you’d probably try their birth date, or an anniversary or something like that.  Let’s face it, people need to be able to remember this number so they’ll have to choose something that relates to them.  The odds of guessing a PIN like this are a lot better.

I was asked to choose a PIN that didn’t correspond to any important dates, so given that restriction, we’ll make an assumption that the PIN isn’t guessable.  Brute force (albeit three attempts) is really all that’s left, so we’re back to one in ten thousand.  But if you add a rule that says you can’t have double digits, then the number of options available decreases to 7,290.  A person who finds my card has a better chance of guessing my PIN than if this rule didn’t exist.

This seems like a case of implementing decisions that sound good without any real analysis.  Have I got this totally wrong?  Does this seem silly to anyone else?

Damo