Security and Usability

I've lately been working my way through the O'Reilly book "Security and usability". I haven't finished it yet, but already it's a great read and there's a wealth of good advice on how to design secure yet easy to use systems.

This is all very relevant to autopackage of course, as the whole area of software installation is rife with as-yet unexplored security issues. Right now, the only security Linux software installation has comes in two forms:

  • Package signing. This stops people putting fake Red Hat packages up on the net, but how many people would download a package claiming to be from Red Hat yet that wasn't on redhat.com or an official mirror? Also guards against cracked mirrors, which are more of an issue when you distribute 10gigs of software from 100 mirrors than when you have an individual application distributed from maybe 1 site.
  • The "all your base" mentality - if it ain't in the distro, it must suck . Needless to say this isn't a definition of security we can sell to Mac users ...

There's so much more we can do! I'll use this page to jot down notes from the book and other thoughts.

Bruce Tognazzini has a useful design checklist:

Achieving balance

  • Are you exploiting the differences between users and attackers?
    • Users know what they are typing in - they are only looking for errors
    • Eavesdroppers, meanwhile, have to construct every character accurately
    • Users are closer to the screen and can therefore read with lower contrast and can better differentiate between green and blue (unless they're colour blind)
  • Are you detecting and exploiting differences in physical location
    • Home
    • Office
    • Airport and other public venues
  • Are you providing a way that your software can track location changes, or the user can casually indicate them?
online movies downloads
  • Are you varying security with the task?
    • Temporary vs archival security
    • "Here" vs "there" vs "en route"
    • "Hide from co-workers" vs "hide from competitors"
  • Does your design exploit the special skills of the population? (eg, elderly people can remember long-past events better than recent ones)
  • Does it serve to reduce the users burden

Authentication

  • Are your passwords restrictive because of:
    • Low upper-limits on password length?
    • Passwords that are system generated
    • Other password rules that encourage writing them down (eg, arbitrary rules on numbers of numbers/punctuation that can break shared passwords)
  • Is it quick/easy to obtain a replacement password

GNU Keyring lets users toggle whether their password is hidden or not: if nobody is around you don't need to hide it visually. We could implement this in autosu (though there are a bunch of interesting issues here regarding how easy it is to suck the password out of autosu itself by a program waiting for the user to run it).

He talks about increasing partnership with users, by advising them of the real risks so people are motivated to use security. We already try this with the "Why do I need to enter my password?" link in autosu. The clarity of the language here could almost certainly be improved.