Is There Value In Them Thar Value Added Security Features?

Feb 09 2007

I was googling for something recently and noticed a relevant hit at a site run by Joel Spolsky. Joel has my permanent admiration as a software-developer-cum-sage. When I encounter something of his that’s relevant to one of my searches, it’s a guaranteed detour.

There I came across a product called Copilot 2.0 produced by Joel’s company, Fog Creek Software. The caption made me grimace: Unlike other remote assistance services, Fog Creek Copilot is secure, easy to use, works through virtually all home or office firewalls, and requires no installation or configuration. But this being Joel’s software and all, I had to take a look.

Here’s how it works: The person needing remote assistance (the pilot) agrees to meet someone who can provide it (the copilot) at a mutually agreeable rendezvous point (copilot.com). The assistance channel is opened only after both enter an identical 12-digit invitation code.

At first blush the rendezvous point is an interesting twist over traditional point-to-point mechanisms like Terminal Services. But I take issue with the product’s marketing message above:

Copilot is secure - the claim
easy to use - redundant in light of the following bullets
works through virtually all home or office firewalls - perhaps this qualifies for easy to use, but certainly not secure
requires no installation or configuration - ditto

So the message boils down to one unsubstantiated claim. I can live with that - it’s no different than any television commercial I suppose.

The real questions that come to my mind are:

Does Fog Creek produce secure code? Given Joel’s remarkably high standards, I’d wager they can and do.

Is Fog Creek adept at writing security software? I’d wager not for several reasons. For one, you have to recruit for a special skill like that, and judging by Fog Creek’s other packages, it’s doubtful they have. For two, there’s the use of the invitation code. In the course of a day one invitation code can be reused by a co-pilot any number of times with any number of pilots. For three, the invitation code easily might be weaker than it should be. A 12-digit keyspace sounds good, but only if the distribution is uniform. We don’t know if the invitation code is random, salted, hashed, encrypted or some combination thereof. Hold this thought for a second.

How much incremental security is added by the rendezvous point itself? None, since it introduces risk: namely man in the middle, to which point-to-point SSL itself is resistant. So if you own the rendezvous point you own the pilot. Depending on the code you might also own the copilot.

Back to the invitation code. The way it’s used it amounts to a pre-generated/multi-user/multi-use authenticator. I say it’s a sign that Fog Creek may not be adept at writing security software because in baseball terms that’s a clean strikeout. If you’re going to bother with a feature like this, it’s important to do it right — especially when the incremental cost of right is minimally more than the way you did it. Right off the top of my head here’s one improvement most security minds would think of: add a second authentication phase which implements dynamic challenge/response. The invitation code gatekeeps the connection and the challenge/response gatekeeps the data flow.

Does that cost a little more? Yes. A lot more? No. Does it introduce a little complexity? Yes. A lot? No. Is the added complexity worth the cost? Of course it is, when you consider that security is one of Copilot’s value propositions.

My point today isn’t to slam Joel and Fog Creek. It’s twofold:

If you buy any products or services with any security criteria in mind, it’s important to dig deeper than you areinclined to. Don’t treat security as an item on your grocery list. In lieu of questions like “Is it secure?” ask questions like “What options did you consider for implementing that security feature, and why did you settle on the one you did?” Or harder ones like “What was the proportionate cost for adding that security feature?” Even if what you learn doesn’t sway your procurement decision, at least you’ve made a more data-driven one.

If you produce any high-tech products or services, you need at least one security expert on your advisory board. If you tout value-added security features, you need at least two. If you’re in the security business, fill ‘er up. You can ignore their dim cost/benefit analyses, but don’t ignore their technical advice. (That doesn’t mean you have to follow it.)

If Joel reads this I hope he’ll forgive me. Regardless, he has my unwavering respect.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.