Last week I came across the paper “Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0″. Although a bit dated, the paper goes through some length to explain why the 5.0 release’s new, well-marketed UI didn’t actually help matters a whole lot, ultimately with the damning experimental result “that when our test participants were given 90 minutes in which to sign and encrypt a message using PGP 5.0, the majority of them were unable to do so successfully.”
The paper is worth reading, but Evan made the point that most of the specific issues the author raised are in some form or another addressed by more recent software, GNU’s Privacy Guard (gpg) among them. I think what I find most confusing in my own use of gpg is ensuring the security of various operations other than encrypting or decrypting or signing or verifying. For instance, I’m willing to put my PGP private key on my laptop, but not on my Athena account on a networked filesystem. I would, however, like to export the “I have verified this key in person” status of several other people’s keys from my laptop to Athena. How do I do that? Will --export convey the information? Can I scrub my private key from --export-secret-keys, and what exactly do you mean that it is “normally not very useful and a security risk”? What about --export-secret-subkeys:does its “special property to render the secret part of the primary key useless” remove the “security risk”? Hm, is --export-ownertrust what I want, or is “ownertrust” an entirely separate concept? Do I need any --export-options?
I realized a similar issue with OpenSSH in a Kerberos environment recently. If a computer has multiple names (for instance, department-of-alchemy.mit.edu and athena.dialup.mit.edu), the default behavior is to only permit using Kerberos authentication with the primary name, and to expect the private key for that name in /etc/krb5.keytab. This means you can only authenticate by logging in to the machine with its primary name (department-of-alchemy, in this case), and using alternate names will not permit Kerberos authentication to work — generally not what you want, and highly confusing.
There is an option to disable the so-called “strict acceptor check”, and permit authenticating with any Kerberos host principal listed in that file (it turns out to stand for key table), so you can put both host/department-of-alchemy and host/athena.dialup in the table. However, once you do so, you change the security implications of that file. Previously, you could list anything you want, and only the key for the computer’s own name would be needed there. So if you’re running test.dialup.mit.edu with different security, you could get away listing host/test.dialup in the key table on both test and production machines. But once you disable the strict acceptor check, and someone has a private key listed in the key table, then they can use that to spoof Kerberos authentication to your machine by requesting the ability to connect to it with an acceptor for host/test.dialup. This makes it very difficult for OpenSSH to ever change the default strict acceptor check behavior, and a little questionable for a downstream source like the Athena software distribution to start setting this default, if we hadn’t previously been doing so.
What’s the right way to communicate security subtleties like this? I think this is a UI problem, somehow, but I can’t really think of a better solution other than copious documentation and hoping that users will have the patience to figure out these models. The “Why Johnny Can’t Encrypt” paper argued towards abstracting certain issues like encryption key format away from the default UI, and in many cases it’s correct. But it certainly seems to me like the strict acceptor check really needs to be understood in full detail before turning it off, despite being a setting that many people would want off, and only causing security issues in relatively rare cases. Is there a better way to present these kinds of security subtleties in UI?
I guess you aren’t the person whom I laughed at when they said they were reading this paper and said something like “The horrible truth is that pgp5 makes gpg look like good UI design.”
> Is there a better way to present these kinds of security subtleties in UI?
I fear there may not be, or anyway not much better. People have finite attention. If I’m a random user, is it worth my time for me to learn the difference between sshing to one name for a server and to another name; to understand what tradeoffs I’m making if I tell my client not to care; and to decide in each instance where on that tradeoff to fall? I claim it’s not. So effective security software for a general audience needs to hide subtleties and choose reasonable behavior on its own.
The problem is similar to how it’s not worth people’s time to become or stay genuinely informed about current events and politics. To the extent that we have (partial) solutions to that problem, they also basically center on simplifying subtleties and somehow making reasonable behavior happen without them.