Posted by: Barnabas Kendall | January 28, 2008

Plugging SmugMug’s “Hole”

Today a blogger named Philip Lenssen wrote a post on Google Blogoscoped that showed how private but otherwise unprotected SmugMug galleries can be downloaded without the owner’s consent. In the wake of the recent and similar MySpace private pictures hole, this seems like a serious PR problem waiting to happen. How long will it be before someone’s “private” SmugMug pictures get some major unwelcome publicity, and SmugMug along with them? I’m sure someone’s crawling all of SmugMug right now and packaging it up as a Torrent file (and no, not me).

Here’s a quick description of the “hole” as I understand it. All of SmugMug’s galleries use an ID number in the URL. If you want to see someone else’s photos, you just manually change the ID number to something else; it’s as easy as changing a URL from smugmug.com/galleries/1000 to smugmug.com/galleries/1001. As long as the photos are not password protected (which is a separate preference setting), you can view the photos regardless of whether or not the user has marked the gallery itself “private”. Mr. Lenssen goes on to describe that one solution is to change from numeric ID numbers to GUIDs which are non-sequential and almost impossible to guess. DonMacAskill, CEO of SmugMug, has not yet posted about this in his blog (why add to the fire?) posted his thoughts about this already, but an e-mail from him is quoted in the original post, admitting that GUIDs would be preferable:

I’m in completely agreement, that GUIDs would help greatly here, but I’m afraid our system wasn’t built for GUIDs, and retrofitting our code and database to support GUIDs would be an extremely expensive proposition. [...] We’re also very open to change – nearly every feature, bug fix, and enhancement is driven by customer feedback, like yours. If our customers (or potential customers) asked us to adopt GUIDs because this was a bigger issue than we were aware – we would.

I have an alternative and cheap solution for Mr. MacAskill that would solve the guessable URL problem without using GUIDs which would be a minor patch to SmugMug’s web code that doesn’t necessarily require any database change, although it would benefit. It would satisfy one of SmugMug’s design goals for private pictures/galleries, namely that you could send a link to a private item. The suggestion is this: leave the URLs alone, but add a checksum key as a separate parameter based on private hash salt. Here’s a simplified explanation of how it would work. Suppose that every user in the system also has a private ID number (which is probably true). When creating a link, SmugMug’s system could calculate a number based on the user ID and the gallery ID and append it on the end of the private gallery URL. For example, the calculation could be the sum of the user ID and gallery ID, divided by an arbitrary number like 29 (this is the private hash salt). If user 123 has gallery 456, then the checksum value would end up being 19 (floor, not rounded). The private URL would be something like smugmug.com/galleries/456?checksum=19. For private galleries only, the page that shows the gallery or image would calculate the checksum each time the page is rendered and show an error message if the checksum is wrong or missing. This is similar to how Scribd allows users to email password-protected documents, without embedding a password in the link itself. For increased security, SmugMug could randomly generate user-specific hash salt in their user table. Either way, this would make auto-crawling private galleries as difficult as transitioning to GUIDs while keeping the existing functionality of private galleries intact.

You’re welcome, SmugMug. This one’s on me. I am an independent technology consultant, so if you would like my help with technology, feel free to contact me.

Responses

Hey Barnabas,

This is a fabulous idea! Thanks so much for suggesting it. I’m not sure this is exactly the approach I’d take, but some variant on it might be perfect.

Let me noodle on it and then maybe ping you with some ideas.

Thanks again!

Don

I should probably have been more clear about the immediate roadblocks to an approach like this…

The big one is that a photo isn’t guaranteed to always be associated with a given gallery, or even a given user for that matter, but the URLs still need to be permalinks.

So I’m left hunting for a suitable non-changing, non-guessable means of generating an additional checksum/key/whatever.

But the idea certainly has merit and likely is much easier to implement than GUIDs.

Still thinking….

You could use different hash mechanisms for the items to protect. To protect private galleries, you could hash the gallery ID with one large private salt integer value, shove that value through MD5 or some other hashing algorithm, and get the first five hex characters (for example).

Private photo links would be similar but based on photo data. You could take the entire photo file name (for example), paste on “ABCDEFGHIJKLMNOP” or something to the end, push it through MD5 and grab the last five hex characters. If IO wasn’t a concern (and that’s never the case) you could MD5 the photo file itself and use that.

My suggestion of using the user ID was just to add something random but repeatable to the hash generator. Best of luck on solving this minor issue.

- Barnabas

[...] we created Keys for galleries and photos/videos and appended them to the relevant URLs. Kudos to Barnabus for planting this [...]

[...] we created Keys for galleries and photos/videos and appended them to the relevant URLs. Kudos to Barnabus for planting that [...]

Leave a response

Your response:

Categories