Abstract or Summary:
Developers create paths for users to tread. Some users will stay on the beaten track; others will diverge and take risky shortcuts. If user-preferred and developer-created paths diverge too much, it is time for the developer to consider a new path. A case in point is the humble password. They fill an important developer need: a cheap and easy mechanism to control access and enforce accountability. Unfortunately, users find the constant requests for authentication a nuisance. They respond by walking down risky paths that compromise the mechanism but allow them to satisfy goals more quickly. The answer, for some researchers, has been to come up with password alternatives. This focus is misguided, since the alternatives do nothing to reduce the authentication footprint. The reality is that developers overuse authentication. The problem is not the authentication step, but rather its position in the path. Authentication is sometimes used even when there is no real need for it. This creates confusion in the user’s mind about the consequences of authentication: sometimes it authorises significant side effects and other times it is difficult to identify its raison d’etre. Here we suggest some developer patterns which minimise authentication requests, emphasising necessity rather than gratuitousness. We believe this will help to ease the current situation by moving towards genuine risk mitigation rather than harming authentication by excessive use thereof.