« cool fire(bird|fox) extension | Main | no need for more anger... »

Basecamp Initial Impressions & Extended Review

I have started to use the new project management system Basecamp from the fine folks at 37signals. I am very much impressed with the system, but I do have a couple of complaints. While usability may be their forte security certainly is not. I have a couple of suggestions for the developers, and a whole heap o' praise.

Ok. Let's get the praise out of the way first.


  • Basecamp is free to run a single project with. this is nice. 10 projects will cost you 20 dollars a month. This is a completely nominal fee for such an excellent product.

  • Every page has an extremely polished design and functionality. So many little touches just make this application feel nearly perfect.

  • When you alter the 10th item on a list of 50, you see a little fade when you save your changes, orienting you on the page. For more info, see this Signal Vs. Noise post

  • Each page is accompanied by collapsible help boxes that not only have great information, but are easy to get out of your way once you no longer need them.

  • Each section has clear notes to an admin on what a client will and will not see. This is very helpful if you have inter-company communications that are not for client eyes, or are just not ready for showing something.

OK. That being said, there are a few problems.

  • You may only assign someone to one of their company's projects. This is no good for contractors who need access to the client's project and do not have projects of their own, per se.
  • There is no security for the XML and iCal feeds. Not smart. These feeds should be removed completely until this has been addressed (although I understand that it is a larger problem than basecamp). The following message is shown near each feed:

    .

    These feeds should definitely be password secured. iCal supports authentication via a pop-up while adding feeds, and most RSS newsreaders will support a URL similar to http://user:password@www.servername.com/yourfile.rss. Users of NetNewsWire from Ranchero, see The NetNewsWire FAQ. A unique URL is only unique until someone's bot finishes cycling through all the options. There is no security through obscurity.


  • A "forgot password" page should never give any information except to the legitimate user. View the following 2 pages:

    Now, it may seem like a minor thing, but someone could harvest a lot of email addresses by plugging in values to the form. A better functional design is to ask the user for their email address and send their username to them that way.


  • A "forgot password" link should never send a password out over a plaintext connection. Provide a hint to the user as a first line of defense. Provide a one-time URL as a second line of defense, with email confirmations at each step. This incorporates a second level of authentication (person X has access to person X's email account) and sends no information over plaintext or on to a page where it is visible by a would-be attacker.

  • There is no SSL on the site, with the exception of the payment screens. SSL is not free, so I understand why people don't automatically tack SSL on to a site. However, user information is just as important as credit card information. One problem that Basecamp faces in this regard is that each client gets their own subdomain on one of a handful of basecamp URLs. To implement SSL for this setup would require getting an SSL certificate for each subdomain (cost prohibitive and unneccessary) or making a sentral login page for each main domain and using a cookie to store session ID information. This is more costly in terms of development time, but the extra security will be greatly appreciated by users.

In conclusion, Basecamp provides amazing value for the price, and is an excellent addition to a freelance or small company workflow. Go give it a whirl.

Comments

While I agree in principle that unique URLs are indeed not the best of security schemes, your proposal for including the user name and password right there in the URL is much worse.

First of all, it lets your password linger in clear sight within the RSS reader. Someone needs only to do cmd-I on the feed and they have your password. Equally troubling is the fact that since there's no SSL, this password is sent in the clear over the wire.

Basecamp allows a very limited set of operations to be performed by holders of a token whereas there's full access to anyone with user name and password. So a malicious user is much more capable of wreaking havok with the complete user name/password set than with the token.

As to the danger of having a bot cycle through the options, this is totally a non-issue with the token. The token consists of a 128-bit md5 key that's dependent on an array of unique properties to the user. Guessing this key with the computing power available to most hackers is measured in hundreds if not thousands of years.

Compare this to the average password quality and the feasibility of a dictionary attack. Using an MD5-key is indeed much more secure.

While "There is no security through obscurity" is a clever catch-phrase and something to strive for, we've choosen the way of the pragmatic and that of personal choice. If you fear for the security with these feeds, you arguebly shouldn't use Basecamp at all as a platform for your secrets. This goes for any non-SSL site online.

But while using the user name and password in the clear along with the URL is a really bad idea, you have many other good ideas on how to improve the security of Basecamp. Thank you for that. They are all on the radar for inclusion in future versions.

iCal definitely has the best authentication for the feeder/link situation that describes Basecamp now, since it, presumably, stores your username/password in the keychain. NetNewsWire will be getting a similar feature, according to their CEO, in response to an email regarding this topic. The username/password combo in the URL is definitely less than ideal, but still requires physical access to the machine or sniffing, which puts any non-SSL site at risk, as you correctly point out.
My main point is not that it is too easy to get the right MD5 hash to unlock someone's feed, it is that once the feed is published somewhere it is out there for good. At least with an explicit authentication scheme, the user can take action to change their password to re-protect their feeds.
That being said, I am not as worried about the security of the feeds except in the case that the URL is published somewhere, I would not have recourse to change it without contacting Basecamp.
Thanks for the comment!

"once the feed is published somewhere it is out there for good. At least with an explicit authentication scheme, the user can take action to change their password to re-protect their feeds."

If you feel your feed has been compromised, you can just change your Basecamp password and you'll be assigned a whole new token for your RSS feed.

I agree that once the aggregators start supporting a shared authentication scheme we should switch to that. But the token-based approach is a more than reasonable compromise for the time being that doesn't require a special aggregator brand to work.

Also, changing your password changes your token. We're changing the RSS security text to reflect that (thanks for the heads up!). That gives you the exact same rights to re-protect feeds as with your password. Only it's much less dangerous to have a leaked password than a leaked token. The token gives only limited access and you're not likely to have used it elsewhere as well.

Hi Jason, Hi David.

Thanks for the discussion regarding the feeds. I hate to give anyone the impression that this issue is as big as the comments here have suggested. ;)

The tip about changing your password is great. Thanks for that.
This issue is definitely coming into play just as feed technology is starting to be integrated into more business uses and Basecamp is certainly not unique in grappling with this issue. Shoehorning RSS into business use is definitely going to have some growing pains, since the initial goal was almost anti-security.

Thanks for a great product, and for the comments!