Bootstrapping Adoption of the Pico Password Replacement System

Abstract

In previous work we presented Pico, an authentication system designed to be both more usable and more secure than passwords. One unsolved problem was that Pico, in its quest to explore the whole solution space without being bound by compatibility shackles, requires changes at both the prover and the verifier, which makes it hard to convince anyone to adopt it: users won’t buy an authentication gadget that doesn’t let them log into anything and service providers won’t support a system that no users are equipped to log in with. In this paper we present three measures to break this vicious circle, starting with the “Pico Lens” browser add-on that rewrites websites on the fly so that they appear Pico-enabled. Our add-on offers the user most (though not all) of the usability and security benefits of Pico, thus fostering adoption from users even before service providers are on board. This will enable Pico to build up a user base. We also developed a server-side Wordpress plugin which can serve both as a reference example and as a useful enabler in its own right (as Wordpress is one of the leading content management platforms on the web). Finally, we developed a software version of the Pico client running on a smartphone, the Pico App, so that people can try out Pico (at the price of slightly reduced security) without having to acquire and carry another gadget. Having broken the vicious circle we’ll be in a stronger position to persuade providers to offer support for Pico in parallel with passwords.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction and Motivation

For normal people, passwords are a pain. Their inadequacy in terms of both usability and security has been repeatedly pointed out [1, 4]. As people must now handle dozens of accounts, passwords are a solution that can no longer scale. Yet passwords continue to dominate as the well-entrenched incumbent because, from the viewpoint of the verifier, they beat every alternative hands down when it comes to ease of deployment [3].

Pico [11], which we briefly describe in Sect. 2, is our ambitious long-term project to replace passwords with a more usable and more secure system that will not require you to memorize any secrets¹. In its quest to explore the entire solution space for the best possible solution in terms of usability and security, Pico is a clean-slate redesign that explicitly gives up on compatibility with passwords. It is immediately clear that, in the short term, this choice will harm Pico’s deployability. Our rationale is that, in the long term, passwords will become so blatantly unacceptable that the world will eventually demand something better; and, by then, Pico will have undergone several cycles of prototyping and testing and will be ready for adoption as a user-friendly, secure and technically sound solution that both users and service providers consider an improvement.

Having said that, in order to be ready for adoption when the time comes, Pico has to be taken seriously by the stakeholders, both on the client side and on the server side. For this reason, while we continue to investigate and develop the architecture without considering ourselves constrained by backwards compatibility, we also intend to provide a plausible migration path from the current password-dominated scenario to a future one in which Pico has replaced passwords. Charting this path is the topic of this paper.

Fig. 1.

The vicious circle opposing Pico adoption.

The main obstacle to widespread adoption of Pico is a classic vicious circle (Fig. 1). Organisations that authenticate their users with passwords are reluctant to change their servers to support an unfamiliar and unproven system, especially if it also requires outfitting every user with a physical gadget at non-zero unit cost. People, on the other hand, will be understandably reluctant to acquire, carry and use a new authentication gadget, even if genuinely easier to use than passwords, if it does not work with the services to which they wish (or need) to authenticate. Our strategy involves disrupting this vicious circle in several places. Where circular dependencies prevent users from adopting Pico before servers have adopted it and vice versa, in this paper we present software modules we have developed to break such dependencies.

Our first contribution, on the client side, is the “Pico Lens” web browser add-on, described in Sect. 3: when you view a website through the Pico Lens, it appears Pico-enabled even if it isn’t, so that you may authenticate to the website using your Pico device rather than by typing your password. This breaks the vicious circle for users because it allows them to use a Pico and reap most of its usability benefits even before their favourite websites start offering native Pico support. In turn, once enough people adopt Pico for its convenience, website operators have more of an incentive to support the full Pico authentication system alongside traditional password login.

Our second contribution, on the server side, is the “Pico Verifier” plugin for Wordpress², described in Sect. 4. It breaks the vicious circle for content providers because it allows webmasters of Wordpress-based websites to make their site Pico-enabled simply by installing the plugin, without any development effort. This plugin also provides a reference implementation of the server side, for webmasters who might wish to develop a Pico-enabled version of their non-Wordpress website.

Our third contribution, on the client side, is the “Pico Prover” app for Android smartphones, described in Sect. 5. This software breaks the vicious circle for users because it allows them to use their existing smartphone as a Pico device, without having to buy (or carry) any extra hardware. The Pico Prover app can to authenticate to both natively Pico-enabled verifiers and to non-Pico-aware websites viewed through the Pico Lens, so it lets users reap many of the usability and a few of the security benefits of a real Pico without any significant investment. If they like the user experience (which, by releasing the app early, we can refine and enhance while taking into account the feedback of many users in a crowd-sourced fashion), they may wish to upgrade to a dedicated Pico, which will eventually be smaller, simpler and more secure. The Pico Prover also provides a reference implementation for the client side.

After a brief overview of the Pico system in Sect. 2 to make the presentation self-contained, the rest of this paper describes each of these three contributions in greater detail.

2 The Pico Architecture in Brief

The Pico system consists of the Pico device itself (a small, dedicated and tamper-resistant hardware authenticator the size of a pedometer or a car key fob), acting as the prover, and a back-end acting as the verifier. Even though the technical contributions described in this paper focus on the use-case of web authentication, in which the verifier is a website, in the general case any entity that authenticates its users (whether with or without passwords—think of car keys) could be augmented with a Pico back-end.

Pico relies on a multi-channel authentication protocol [14] in which an additional channel (acquisition of a QR code [7] in the current implementation) conveys the user’s intent to authenticate to a designated verifier. The verifier signals that it supports Pico authentication by displaying a Pico visual code, perhaps alongside the conventional login prompt for user name and password. The human prover signals her intent to authenticate to a particular verifier by acquiring the verifier’s QR code with her Pico device. This action initiates the execution of the Pico authentication protocol, which mutually authenticates the verifier to the Pico and the Pico to the verifier.

In the current implementation the Pico system uses the SIGMA protocol [8] for mutual authentication and generation of a symmetric session key. The Pico prover and back-end verifier create digital signatures to prove ownership of a public key, which is their long-term public identity. Pico has adopted the “I” variant of the SIGMA protocol [8], in which the verifier must authenticate its identity to the prover, before the prover reveals its identity to the verifier, preventing any privacy loss to verifiers presenting “counterfeit” visual codes. To protect the user’s privacy further the Pico uses a different key pair for every account so that colluding verifiers cannot link accounts belonging to the same user. A run of the SIGMA protocol also yields a fresh symmetric session key, which the Pico and verifier use for continuous authentication.

In some cases, for example when logging into a local computer or when opening a Pico-enabled door, the Pico prover device talks directly to the Pico verifier that displays the QR code directly. In other cases, though, most notably when logging into web sites, a third device is involved: when you authenticate to a website with your Pico, you actually access your account for that website through the web browser of your normal computer. In such cases the website provides the authenticated Pico with a “session delegation token” (a cookie) that the Pico then transfers to the web browser to delegate³ the session it has authenticated⁴.

When the verifier is remote, as in the case of a website, the Pico needs a connection to the Internet and a connection to the user’s web browser so that the Pico can transfer the session delegation token to the web browser after authenticating. In our implementation as of March 2014 the Pico connects to the user’s computer via a Bluetooth Personal Area Network (PAN) and tunnels out to remote services via this interface as well so that Pico doesn’t need to have its own Internet connection via WiFi or via a mobile phone network.

Pico offers continuous authentication, whereby the Pico device authenticates to the verifier at regular intervals without user intervention, so long as the Pico remains unlocked and in proximity of the computer running the web browser. The verifier may thus keep the session open for as long as necessary but close it immediately when the user is no longer present, minimising the window of vulnerability during which another person could hijack the session if the user left the terminal unattended. In the current prototype we detect proximity with a heuristic based on Bluetooth signal strength, though in the future we plan to adopt a more secure distance bounding protocol [5, 6].

As with any token-based authentication method, the Pico system must protect the token against misuse by others who might find or steal it. In our design this is achieved through the Picosiblings mechanism [11, 12]: the Pico device locks up (with its credentials encrypted), pauses the continuous authentication of any active session, and stops authenticating new sessions whenever it cannot sense the “aura of safety” around its owner. The “aura” is defined by the proximity of a sufficient number of other electronic devices (the Picosiblings) worn by that person. A biometric sample and a connection to a home server also act as special Picosiblings that offer additional protection properties and allow remote revocation. Because this Picosibling-based locking mechanism is independent of the normal operation of the Pico device and, particularly, of the “vicious circle of adoption” alluded to above, it will not be discussed further in this paper.

The credentials stored in the Pico device are backed up automatically, in encrypted form, whenever the Pico is plugged into its docking station for recharging. Backup, too, despite being a fundamental component of the Pico architecture, is independent of the “vicious circle of adoption” and will not be discussed further in this paper.

3 The “Pico Lens” Firefox Add-On

The “Pico Lens” is a web browser add-on that rewrites websites on the fly to make them appear as if they support Pico alongside password authentication. The Pico Lens detects web pages containing login forms and adds a Pico visual code to them, alongside the existing username and password fields, so that Pico users have the option of authenticating with their Pico instead of typing their password.

Although the underlying methods used by the Pico to authenticate to Pico-enabled and only Lens-enabled websites are quite different, our aim was to make the user experiences as similar as possible. The end result in both modes of operation is the same: the user’s web browser receives a session cookie granting access to the user account. Behind the scenes, however, what happens is rather different.

3.1 Pico Authentication

For comparison, authentication to a fully Pico-enabled website (that is, a website that supports the real Pico authentication protocol) is described by the following sequence of events.

• 1. The user, whose web browser has a Pico add-on installed⁵, navigates to a login page.

• 2. The login page includes a visual code encoding the public key of the service. If the full Pico Lens add-on is installed, it detects that the website is Pico-enabled (for example through a pico-enabled HTML meta tag.), and refrains from rewriting the page.

• 3. The user scans the visual code with their Pico.

• 4. If the user has multiple accounts for the website, they select one from the list displayed by the Pico. If the user only has a single account for the website, as is common, this step is skipped.

• 5. The Pico and the website mutually authenticate.

• 6. The website sends the Pico a fresh session delegation token, which for a web authentication takes the form of a set of cookies and a URL.

• 7. The Pico sends the session delegation token to the local terminal via the Bluetooth PAN.

• 8. The Pico add-on causes that browser to navigate to the URL contained in the session delegation token.

When a website is not Pico-enabled, the Pico Lens add-on allows the user to follow the same work flow, despite the differences in the underlying mechanism.

• 1. The user, whose browser has the Pico Lens add-on installed, navigates to a login page.

• 2. The Pico Lens detects a login form on the page, and displays an authentication visual code containing the domain name of the website (Fig. 2).

• 3. The user scans the code with their Pico.

• 4. If the user only has a single account with the website, as is common, this step is skipped and the Pico proceeds to mutually authenticate the website. Otherwise the user selects an account for the website from the list displayed by the Pico (for each account the Pico device holds the username/password credentials used to authenticate).

• 5. The Pico internally loads, fills in and submits the login form using its stored username/password credentials for that account, tunneling an end-to-end HTTPS connection to the website through the Bluetooth PAN established with the local computer.

• 6. The Pico receives the website’s response to the form submission and creates a session delegation token consisting of any cookies set in the response and the address it was redirected to.

• 7. The Pico sends the session delegation token to the user’s computer via the Bluetooth PAN. In the web browser, the Pico Lens installs the set cookies and follows the redirect, so that the user is logged in.

Fig. 2.

QR code presented by the Pico Lens add-on for authentication to a website that does not natively support Pico.

3.2 Pico Lens Pairing

Before a user can log into a Lens-enabled website with their Pico, they must store on in its encrypted storage their account credentials for that site and the Pico must learn how to fill out the login page on behalf of the user. The interaction is somewhat different to the “pairing” interaction with a Pico enabled site. Assume the user already has a password-based account with the web site and now wants to be able to log in with their Pico when viewing the site through the Pico Lens.

• 1. The user, whose web browser has the Pico Lens add-on installed, navigates to a login page.

• 2. The Pico Lens add-on detects a login form on the page and thus rewrites the page⁶ to display an “authentication” visual code containing the domain name of the web page (Fig. 2).

• 3. The user, having not yet stored any credentials to their Pico for this website, ignores this first QR code, types their username and password in the login form and submits it as if without Pico.

• 4. The Pico Lens add-on detects the form submission, captures the name-value pairs being submitted, and offers to save these credentials on the user’s Pico (Fig. 3), much as an in-browser password manager⁷ would.

• 5. The user accepts this offer and the add-on displays a “pairing” visual code containing the submitted credentials⁸, as well as the domain name of the website.

• 6. The user scans the visual code with their Pico.

• 7. The user confirms the pairing details and the username and password credentials are saved in the Pico’s encrypted database, with the website domain as their lookup key.

Fig. 3.

Dialogue presented by the Pico Lens add-on after a login form is submitted.

3.3 Pico Lens Design Trade-Offs and Future Work

The current implementation largely mimics existing in-browser password managers but is still a work in progress at the time of writing. Design decisions still to be finalised, possibly with the help of user studies, include at least the following.

First, we could do better in step 6, security-wise, by encrypting the username and password to the Pico before encoding them into the QR code; but we’d need some key for encrypting the message from Lens to Pico, and what would be the most usable way of establishing that⁹?

Second, we might consider using radio rather than the visual channel in step 6, sparing the user from having to scan a visual code, although there may be technical difficulties on platforms where the add-on is not allowed to open a socket.

Third, instead of making it the responsibility of the user to choose a suitably strong password, the Pico itself might choose a random password as hard as the website’s policy will allow, to ensure greater randomness than can be expected by letting a human choose a secret [2]; the difficulty there being that the Pico would have to be informed about the constraints imposed by the website’s password policy (e.g. certain characters disallowed, password length not to exceed some limit, etc.)¹⁰ or discover them by trial and error.

We assume that many web users will already be familiar with the concept of a password manager since most modern web browsers incorporate one that pops up and offers its services when appropriate. An encrypting password manager, even though it stores your passwords on your computer thus exposing them to network intruders¹¹, offers a significant improvement in both security and usability compared to plain passwords because it allows you to use stronger passwords that are all different and that you don’t have to remember nor retype. The fact that Pico can be seen as a portable password manager will allow users to mentally associate the former to the latter, making it easier for people to adopt Pico because they won’t have to form a totally new mental model for it.

In contrast to a password manager, the username-password pair is stored not on the computer running the web browser but within the encrypted storage of the Pico (just as the private-key cryptographic credentials would be in the fully-Pico-enabled use case [11, 12]) making the credential more strongly protected against network attacks than with the in-browser password manager. Although the implementation is very different, we are keen to maintain consistency in the user’s mental model (“it’s my Pico that holds my credentials”) between the two cases of visiting a Pico-enabled website and visiting a legacy website through the Pico Lens.

The Pico visits the target website’s login page independently from the web browser, rather than sending the password to the web browser; therefore, if the terminal is compromised, only individual session cookies can be compromised, rather than the long-term password. In this respect, too, the Pico Lens is a security improvement on existing password managers.

The Pico Lens add-on cannot provide continuous authentications for non-Pico-aware websites because, in order for continuous authentication to work, the back-end must accept “pause” and “resume” methods for the session, besides the standard “start” and “stop”. A session that has been paused is inactive but retains its state; this must be explicitly supported by the back-end verifier. A session with a non-Pico-enabled website can only be either “logged in” or “logged out”.

In our current implementation the Pico connects to the user’s computer via a Bluetooth Personal Area Network (PAN) and tunnels out to remote services via this interface. Setting this up is, whist reasonably straightforward, is non-trivial. Further work is required to ensure that the solution is easily deployable by geeks and grannies alike. Since presenting this work at the SPW in March 2014 we have been working on replacing the Bluetooth PAN with a web-based rendezvous point. Whilst introducing the need to securely pair the Pico and web browser, removing the dependency on Bluetooth significantly simplifies deployment of the solution.

The current Pico Lens add-on implementation is a technology demonstrator of the core insight that we can offer users the Pico experience even before their favourite websites are Pico-enabled. For actual deployment, though, we may have to revisit some of our implementation choices; the leading browser is now Chrome¹² rather than Firefox, although their add-on architectures are rather similar.

4 The “Pico Verifier” Wordpress Plugin

Wordpress, originally a blogging platform, is currently the leading content management system on the web¹³. Our “Pico Verifier” plugin for Wordpress implements the back-end side of Pico for any website running Wordpress. It allows users to log into the website using the genuine Pico protocol (not a simulation, as would be the case with the Pico Lens) while of course still allowing traditional password-based authentication.

With the Pico Verifier plugin installed on a Wordpress website, the login page is modified to include a Pico visual code, alongside the usual username and password prompt. Unlike the visual codes added by the Pico Lens, the ones the Wordpress plugin adds are in the HTML returned by the web server. The Pico visual code contains the name, address and public key of the website (see Fig. 4).

Fig. 4.

Example visual code added to the login page by the Wordpress plugin.

To authenticate to the Wordpress website, the user scans this QR code with her Pico. Provided the Pico is already paired with her user account on the website, the Pico then initiates the mutual authentication protocol of Sect. 3.1 with the website’s Pico verifier (also provided by our Wordpress plugin). If authentication is successful, the Pico verifier returns to the Pico a session delegation token, which the Pico uses to delegate its authority to the web browser as discussed in Sect. 2.

Users can create a Pico-enabled account by scanning another visual code (similar to the one shown in Fig. 4) which the plugin adds to the Wordpress account creation page. The plugin also adds a “Pico” section to the Wordpress account management page. Here users can unlink a Pico which is already linked with their account and a QR code is added to allow the user to link a new Pico. For administrators, new Pico-related settings are added to the site’s settings page.

Normally, once mutually authenticated, the Pico and the service execute a continuous authentication protocol over the established secure channel. When the Pico is out-of-range of either its Picosiblings or the terminal, the session is first paused and then eventually terminated. Terminating a session is straightforward. Pausing is more difficult, as Wordpress wasn’t designed with pause/resume in mind, and this feature isn’t currently provided by our plugin.

To experience a Pico compatible Wordpress blog requires that both websites and web visitors install and configure some software. The demands placed on the website are relatively modest—to install our Pico Verifier Wordpress plugin. In contrast, each user (prover) is required to install and setup multiple pieces of software (browser add-on, Bluetooth device driver etc.) and to provide network connectivity between the Pico, their computer and the website. Our future work includes simplifying these requirements in order to make Pico easier to deploy.

5 The “Pico Prover” Android App

It seems prudent that an authentication token holding all your login credentials should not be a general-purpose computing platform, with unfettered networking facilities, on which users merrily install arbitrary code of dubious provenance [9]. For this reason (as well as to be simple and easy to use) the Pico client is ultimately intended to be a dedicated single-purpose hardware device rather than a smartphone app. However, users tend to be extremely reluctant to carry one more device. And a smartphone can already simulate, if not the form factor, at least most of the intended functions of a Pico. It therefore seems reasonable for us to release a smartphone app that will allow users to try out the Pico functionality at no cost—without having to acquire a physical Pico (which we haven’t yet built anyway) nor having to carry one around (assuming they’d already carry their smartphone regardless). While they’re trying out Pico, users may still retain traditional passwords for the few accounts they consider most valuable and only use Pico for their more numerous lower-value ones. The risk introduced by the possibility of their long term credentials being exposed by malware on the smartphone is therefore limited.

We consider a dedicated tamper-resistant hardware token and the use of a consumer computing device such as smartphone as being at opposite ends of a design spectrum. Within this spectrum there are several other interesting options, such as the use of a Trusted Execution Environment (TEE). A TEE is an isolated execution environment in which sensitive or security enforcing functions can be executed. The Protection Profile for TEE—produced by the Global Platform collaboration—targets the Common Criteria Evaluation Assurance Level EAL2 (“Structurally tested”). Thus an implementation of the Pico Prover App using this technology would offer security benefits over a basic smartphone app.

Despite TEEs based on ARM’s TrustZone technology being present in over 100 million handsets, the software running in the isolated environment has, until recently, been tightly controlled by handset manufacturers. With the advent of the Samsung S4 the TEE has been opened upeta third party developers and this trend is likely to continue.

Despite the security benefits provided by a TEE, ensuring a trusted path to the user is a significant residual problem: malware can’t access the data segment of the TEE-secured Pico Prover app, but it could simulate its screen. Because Pico does not require the user to remember or enter secrets, such concerns are somewhat mitigated. However, careful thought is needed to ensure that a malicious app can’t trick the user in some elaborate way or abuse the API between the rich and trusted side to extract sensitive data such as keying material. A detailed analysis of Pico executing within a TEE on a smartphone would make interesting future work.

During the transition phase, the smartphone app will support both the native Pico protocol and also the Pico Lens protocol. Therefore, an important constraint placed on the Pico Lens solution is that it should be as usable as the native Pico. Distributing the Pico Prover as a free app allows us to crowd-source feedback about the usability of the solution and ensure that we are meeting this goal.

6 User Acceptance

To date the security and usability benefits of Pico have only been considered by technologists [3]. The Unified Theory of Acceptance and Usage of Technology (UTAUT) [13] applies to technology adoption the ideas of the more general Theory of Planned Behaviour (ToPB) from social psychology. The UTAUT model postulates that a user’s intention to adopt a new technology is driven by four constructs:

• Performance Expectancy

  The root component of which is perceived usefulness.

• Effort Expectancy

  The root component of which is ease of use.

• Social Influence

  Similar to social norms in the ToPB model.

• Facilitating Conditions

  Objective factors that influence the ease of adoption of the technology.

As users often hold inaccurate notions of security and of the importance of security measures [1, 10], the stated security benefits need to be reconciled with the benefits that end users perceive Pico to offer. However, without a working implementation and more importantly without compatible services to log into, validating these benefits would be tricky. In our initial work we have focused on providing “Facilitating Conditions” that allow us to perform large scale user studies to validate Pico’s assumed benefits.

The solutions presented in this paper allow Pico to be adopted by a broad user community and used with legacy services based on password authentication. The insights gained from users adopting Pico in a day-to-day setting will highlight what we got wrong and inform changes to our design. Reporting and acting on these findings is a significant and exciting part of the future direction of the Pico project.

7 Conclusions

We still believe that, in our quest to produce a more usable and more secure password replacement, it would be a mistake to limit our horizon to solutions that are compatible with passwords: it may well be that better solutions exist beyond that horizon, and we want the freedom to explore those regions of the design space too.

On the other hand, we fully realise that a realistic solution requires a plausible path to deployment and that, when encouraging major players to adopt Pico, we cannot act as if passwords weren’t already a strongly entrenched incumbent. The vicious circle undeniably exists: websites won’t have any incentive to support Pico authentication until users already have Pico devices, and users won’t have any incentive to get a Pico unless it works with their websites of interest.

Our strategy is therefore to break this vicious circle in several places. We have shown how the Pico Lens browser add-on allows users to reap the benefits of a Pico device even before the websites support it. We have shown how the Pico Verifier website plugin allows webmasters (of Wordpress sites) to support Pico at no development cost. And we have shown how the Pico Prover smartphone app allows users to try out Pico for some of their accounts without having to buy anything or carry any additional gadgets.

A significant advantage of this bootstrapping strategy is that allows us not to compromise on the purity of the Pico design: the clean-slate Pico is incompatible with passwords, but the solutions presented above are stepping stones that bridge this compatibility gap because they interwork with both legacy passwords and Pico, thus allowing for a transition phase.

Our next step will be more organisational than technological: we need to get the website operators on board—especially the big ones. If we can demonstrate that a critical mass of users finds the Pico Prover app and the Pico Lens add-on to be more usable than passwords (and we’ll have to work hard at simplifying the installation process) we’ll be in a good position to persuade the big players that it’s worth supporting Pico as an alternative authentication method. This will in turn attract more users and we’ll finally move from a vicious to a virtuous circle.