I heart PINs is a sorry tale of failed delegation (of a burglar alarm PIN). That failure was two-fold. Firstly, delegating a static shared secret such as a PIN or password invariably results in it being written down. Once written down the PIN has become a bearer token, fundamentally changing the security properties of the system. This introduces new threats whilst potentially mitigating others (given the importance of availability, loss of the token is a significant concern).

Systems that rely on users to develop ad-hoc strategies to ensure that they get the job done are flawed by design. User’s should not be expected to understand the – sometimes subtle – implications on security of simply making a system work for them.

Secondly, delegation by handing over your PINs or passwords doesn’t respect the principle of least privilege.

Every privileged user of the system should operate using the least amount of privilege necessary to complete the job. —Jerome Saltzer, Communications of the ACM

In the case of burglar alarm, I don’t need the rights to disable and set the alarm forever. But as it’s all or nothing that’s exactly what I get [1].

Do users really need delegation?

Delegation is defined by security folks as:

A process whereby a principal authorizes an agent to act on its behalf by transferring a set of rights.

Normal people don’t see it like that, delegation is simply part of getting the job done. The canonical example of where delegation is performed contrary to the expectations of the system’s designers is EMV, otherwise know as Chip and PIN.

Chip and PIN is a multifactor authentication scheme, that is you need both the card and the PIN to authenticate yourself. Clearly the designers of the system assumed that the PIN is a secret (know only to the card owner) and that in normal usage the card is in the possession of its owner. Good assumptions. However, where’s the fun in doing exactly what system designers assume?

Say you want to send our-Anthony down to the local offy to get some fags. With Chip and PIN you simply hand over your PIN and card. That this is possible accounts significantly for user’s positive attitudes towards the system. This is again a case of all of nothing and being a lazy little get Anthony could indeed withdraw all you money (up to your daily limit).

In contrast, if Chip and PIN where designed using a biometric for example, a finger/palm print or a vein pattern. Jim Royle doesn’t get his fags. Again it’s all or nothing.

Can we design systems then allow users to delegate authority it the way that the desire? Or is it simply too onerous? Would the difficulty in remembering a rarely used process for delegation out way any benefits? This is all waiting to be explored as we begin to think seriously about including authorization into usable-security.

Lessons for usable security researchers

So what have we learnt? Delegation isn’t some esoteric security primitive, it is how normal people actual use systems; whether that’s delegation of keys to tradesmen, login sessions to trusted colleagues or burglar alarm PINs to siblings. Both existing technologies and there proposed replacements fail to properly account for user’s desire to delegate; unless you’re Tony Hart delegation of a graphic password isn’t going to work too well. Most importantly when considering authentication schemes we should ensure that authorization is considered to.

1. Conceivably the PIN could be changed, limiting the window of vulnerability. In reality though it’s not going to be is it?