Systems with cryptography should always have minimal workarounds

February 3, 2013

Here is something that I've come to firmly believe: if you have software that uses cryptography, your software should either absolutely refuse to work if the cryptography rejects something or it should have a minimal workaround for the failure; the worst thing you can do is have a nice 'turn off all crypto' option. I wrote one version of why in this entry about a Yum cryptography failure, but I want to repeat it generally because this is a very important point for usable real-world security.

In general, this follows directly from observed user behavior and from the fact that people mostly don't care about security. When your system tells people that there is a cryptography problem, real people have two choices; they can give up entirely or they can tell your system to go on anyways. Very few people will chose the first option because very few people are going to give up on what they wanted to do. If the only option you give people for going on is totally disabling your cryptography, that is the option that people are going to use. This is a terrible result. You have just forced people to throw away all of your protection, even (or especially) in a potentially dangerous situation (after all, your cryptography protections already triggered once). A much better option is a minimal one, one that turns off or overrides only enough cryptography to sidestep the specific current problem.

In short: if your cryptography rejects something, people are going to go on anyways if it's at all possible. You want them to go on in a way that does as little harm as possible.

Browsers are a decently good example of this. When you connect to something with an invalid SSL certificate browsers don't force you to completely turn off SSL certificate verification; instead they let you override it just for the particular site. Your system should provide something similar.

Note that there are hard problems when dealing with a cluster or a cascade of errors. If your system is processing a bunch of independent objects, for example, you may not want to stop at the first crypto error but instead check everything and then summarize the results. This gives you a chance to work out the real minimal workaround (and also to notice if this seems to be a really big problem), because it doesn't take more than a few rounds with the user experiencing successive failures before they'll reach for the big red 'turn off all crypto' option.

Written on 03 February 2013.
« A fundamental problem with the trackback protocol
What good cryptography error messages need to include »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Feb 3 02:12:06 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.