Security bug management done right: Tarsnap

Posted on 2011/01/20

0


Tarsnap (http://www.tarsnap.com/) is a backup solution with emphasis on security; it is conceived, developed and maintained by a single author (Colin Percival). To put it simply, the user downloads and runs an open-source client software that encrypts the data to be saved, and copies it on remote servers recurrently. No one except the user can access the unencrypted data: even if the information is in the “cloud”, it is safe because it’s encrypted with a strong algorithm and no one knows the decryption key except for the user.

Tarsnap is designed to appeal to people who know and care about protection, people who do not believe in “security through obscurity”. The fact that the client code is open source is obviously a good point in favor of the project: you can choose to trust the developer’s skill, or you can choose not to trust it and see for yourself. The ability to choose is important and builds trust between the parts involved.

As much as one can be theoretically safe, the real world is not perfect. Softwares are buggy, systems fail, … Recently the Tarsnap developer discovered a bug that could be exploited by someone with access to the encrypted files. The possible entities that could be able to decrypt the data are the Tarsnap developer’s himself, the server’s hosting company (Amazon) and the US Government. The Tarsnap author’s response (http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html) can be summed up with:

  1. Fix the bug
  2. Publish the new client version
  3. Notify the users and the public
  4. Explain the technical details of the bug
  5. Analyze and expose the impact of the bug
  6. Issue refunds to users, even those that decide to leave the service because of this bug
  7. Start a campaign of bug hunting (with money rewards)

From my point of view this is the proof that Tarsnap’s author is honest, skilled, brave and compassionate. The response could appear exaggerate, but the service is advertised “for the security paranoid”, so the expectations are higher than usual. Other than that, we are used to another kind of behavior: most software companies stop at the first two points of the response, ignoring completely its user base needs.

I think this is a good example of managing security bugs, and I’d really like to see this behavior more often, not only for software but also for city utilities, banks and any company that has access to sensitive data.

See also:

Posted in: Security