Visual Code Authentication Schemes

We find that many schemes in the literature (including, previously, our own) re, unfortunately, vulnerable to relay attacks. We explain the inherent reasons for this vulnerability and offer an architectural fix, evaluating its trade-offs and discussing why it has never been proposed by other authors. Introduction We consider a relatively new class of web authentication schemes, currently attracting significant academic and commercial interest, which we refer to as visual code authentication schemes.

A user may log into a website which supports such an authentication scheme by scanning a visual code, such as a Quick Response (CRY) code [1], using their hand-held authenticator device, encounter scanner. The scanner is generally a smartened, but might be a dedicated hardware gadget. The user carries their scanner at all times, or at least whenever they might want to authenticate to a website; the scanner may have a mechanism to prevent its misuse if lost or stolen. Our own Pico system [2] is of course in this class too.

Such schemes are interesting because they have some important usability benefits which passwords do not; specifically, there is nothing for users to remember or type . Furthermore these schemes are resilient to conventional pushing because the long-term secrets never leave the scanner and so an attacker cannot trick the victim into revealing them. However, visual code authentication schemes present a new risk. Because the information in a visual code is not human-readable, and visual codes are easily relayed, a user may be tricked into scanning a visual code displayed outside its intended context. 1 2 Cuff. Functions of Memory’s, Scalable-for-users and Nothing-to-Type in the Usability, Dependability and Security (DUDS) framework of Bandeau et al. [3]. As defined in the ACIDS framework [3] Authors’ preprint. In B. Christianson et al. (deeds), Proceedings of Security Protocols Workshop 014, Springer LENS. We have surveyed a range of schemes currently in the literature, some commercial [4,5] and some academic [2,6,7]. We find there are significant structural similarities between the schemes and that they all area susceptible to attacks in which the victim inadvertently authenticates a session for the attacker.

This paper makes the following contributions: – We show that the architecture of many visual authentication schemes currently in the literature leaves them inherently vulnerable to attacks that relay the visual code, allowing an attacker to gain control of sessions authenticated by other users. We present our proposed solution, session delegation, now adopted by Pico, which uses an additional communication channel to prevent the aforementioned relay attacks, and discuss why no other scheme has adopted anything similar. We discuss extensions to our session delegation protocol and some alternative means of mitigating these attacks, while considering their impact on the usability, dependability and security of the system. Visual code authentication schemes All of the schemes surveyed offer a similar user experience and share some crucial architectural features. In this section we describe these commonalities ND then review the individual schemes in more detail. 2. 1 User experience when authenticating When a user visits a website in their web browser, the login page includes a visual code, possibly alongside a traditional surname and password login form.

In order to login, the user scans the code with their scanner, which authenticates to the website identified by the visual code. After the scanner has authenticated on the users behalf, the web browser receives a session cookie which grants access to the user’s account through their browser. The scanner is responsible for the generation and retention of all keys and secrets. As a result, using the scanner with arbitrarily many accounts and services does not require additional cognitive (and in particular memory) effort on the part of the user. 2. Protocol Crucially, these authentication schemes must also be able to authorities a web browser running on a different host than the scanner. We call this process browser authorization. Without this ability users would be restricted to logging into, and using, websites only on their scanner. But it is this crucial feature, and the 3 Or were, in the case of Pico. Common approach taken by the surveyed schemes to provide it, that leads to he security vulnerabilities we describe in section 3 below. The schemes surveyed use differing protocols for the actual authentication between the scanner and the website.

However, we found extensive similarities between the mechanisms used to perform the browser authorization and, below, we show a generalized version of the overall protocol, to which the concrete implementations can all broadly be mapped Fig. 1 shows the sequence of messages sent between the users web browser, B, their scanner, S, and the website, W. Website website identifier, browser nonce 4 5 3 auto protocol session cookie via visual code Web Browser Scanner Fig. 1 Generalization of the flawed browser authorization protocol used by the reviewed visual code authentication schemes.

The figure shows how a session cookie, cue , for user U is installed into their browser B. 1 . The user navigates to the login page of a website W in their web browser B. The login page returned by the website includes a visual code containing the websites address (or identifier) W and a fresh browser nonce, an . Note that the request and response are performed over HTTPS and therefore encrypted under a TLS session key, KGB . {W, }KGB At least as far as we can infer-?some schemes have not openly published a omelet specification. 2.

The website address W and browser nonce N.B. are transferred to the scanner, S, when the user scans the visual code on the websites login page. W, N.B. (visual channel) 3. The scanner authenticates to the website using a scheme-specific authentication protocol. The website looks up the user account, U , associated with the identity authenticated by the scanner. Subsequently, or as part Of the authentication protocol itself, the scanner securely sends the browser nonce to the website. S. W: JIB}SSW The website is then able to associate the nonce N.B. with the account U . The browser makes another request to the website, again over HTTPS, which includes the browser nonce N.B. , with the intention of “trading in” this nonce for a session cookie. B W {N.B. YK’S 5. After looking up the user account IS associated with N.B. , the website W returns a session cookie cue . This cookie grants access to user U ‘s account, as if the user had authenticated using a typical surname-and-password-based scheme. B: {cue }KGB If the browser had sent its second request (4) before the scanner had validated the nonce in (3) with the authentication protocol, the website would to have granted a session cookie in this step. . 3 Schemes in the class Method and System for Authenticating a Issuer by Means of a Mobile Device (2009) This patent held by GM Solutions Globules Internet S. A. , describes a visual code authentication scheme in which users authenticate to remote services with a trusted application running on a mobile phone. In this scheme the user selects the service to authenticate to by acquiring a visual code displayed by an entrusted device. The visual code contains both a random challenge and an identifier of the service to authenticate to.

On canning the visual code the mobile device creates a response to the challenge by signing it with a private key. The scheme uses Identity Based Encryption (I BE) allowing the response to be verified using the users public identity such as an email address. In common with the other schemes described here, the scheme links the login session on the entrusted device with the scanner’s response using the random challenge contained in the visual code. Thus, this random challenge is directly equivalent to the browser nonce shown in Fig. 1.

Snappers Snappers [8] is a visual code authentication system for web applications in which users authenticate using a smartened application. In this scheme the user selects the service to authenticate to by acquiring a visual code displayed by an entrusted device. The visual code contains both a random challenge and an identifier of the service (the relying party) to authenticate to. On scanning the visual code, the mobile device creates a response to the challenge comprising of the WHAM-SHAH hash of the entire challenge message using a pre-shared secret as a key.

The provider verifies this responds and, if successful, the browser session is authenticated with the appropriate account. The challenge nonce (sometimes referred to as a session key) in the visual code is directly equivalent to the browser nonce. Snappers explicitly acknowledges that it does not mitigate active man in the middle attacks such as those discussed in this paper. Pico (2011) Stannous Pico [2] is a visual code authentication scheme intended for a dedicated hardware device, although it could also be implemented, trading off security for convenience, as an application running on a smartened .

Pico also includes a novel locking mechanism dependent on the proximity of a number of other, smaller devices referred to as Possessing, as well as on proximity detection between the user’s Pico and their web browser (or rather the computer it is running on), allowing the user’s session to lock automatically when they are away. A smartened-based research prototype created by Titan [l under Stannous supervision . Another smartened-based prototype independently developed by If [9] includes a session in the visual code that is directly equivalent to the browser nonce above. Sir (2011) van Rickrack’s tiger [6] is a prototype smartened-based visual code authentication system. The scheme uses the Oath Challenge Response Authentication (CRA) [1 0] protocol to authenticate the user to services. The user has a four-digit PIN, in addition to a secret held by the phone, for logging in to each of their accounts. In this scheme the visual code contains a random challenge that is directly equivalent to the browser nonce. Login Using CRY Code (2012) This patent held by eBay Inc. Describes an authentication scheme that uses a visual code authenticator to broker secure log-ins to websites from devices that may be insecure. The scheme uses a trusted application, running on the mobile device to authenticate to a single third-party Identity Provider (LDAP). The contents of the visual code displayed on the entrusted device are passed to the LDAP by the authenticator. The contents of the visual code are encrypted As already envisaged in the original paper [2] as well as in our other paper in these proceedings, “Bootstrapping adoption of the Pico password replacement scheme”. ND can only be read by the LDAP. Upon validating the contents of the visual code, the LDAP issues a challenge to the trusted device, such as requesting a password. Once the user has authenticated, the Dip informs the relying web service which maintains an association between the CRY code contents to active login sessions. The relying web service then updates the status of that login session. The information contained in the visual code is sent from the LDAP to the website to identify the authenticated web session.

Although the description given in the patent [5] is a bit vague and obscure, it seems reasonable to assume that this data is somewhat analogous to the browser nonce. Quart (2013) Hoard’s Quarter [7] is a research prototype visual code authentication system with significant similarities to Pico. The authenticator has a shared secret for each service, unlike Pico which uses asymmetric raptorial and Quart uses a mobile application rather than a dedicated hardware device as the visual code authenticator. In this scheme the login identifier is directly analogous to the browser nonce.

Secure Quick Reliable Login (2013) Another recent smart-phone-based scheme is Secure Quick Reliable Login (CURLS), proposed by Gibson [12]. Visual codes used in the CURLS scheme contain a URL which includes a session id and points to an authentication service. The CURLS app signs this URL and then sends the signature to the authentication service over HTTPS. It uses a different public-private key pair for each service but, unusually, these key airs are not stored, but are derived from a master secret and master password when needed.

The system specifies a revocation protocol to be used when a CURLS device is lost or stolen. The session id contained in the URL in the visual code is directly equivalent to the browser nonce. Attacks 3. 1 Core vulnerability Visual codes are not human readable; so, whilst acquiring a visual code reflects the users intent to authenticate, it is unclear to the user what they are authenticating to, or whether the information in the visual code is fresh. Although the visual channel itself can reasonably be assumed to be modifiable, the user’s web browser is not a trusted display.

Specifically it does not prevent relayed visual codes from being displayed. The attacks we describe below all exploit the same core vulnerability. In all cases the attacker (who uses browser B ) seeks to obtain a cookie, cue , which will give them access to victim IS ‘s account for a given website W . 6 There is also a commercial mobile application [1 1] of the same name, but it is equivalent to a password wallet and bears only a superficial resemblance to the other schemes discussed here.

For each attack, the attacker makes a request to W and gets back a visual ode containing W, N.B. (see step 1 in the description of the protocol above). W The attacker then relays this visual code and convinces the victim to scan it, thereby causing the users scanner to authenticate to W and link U ‘s account with an (see steps 2 and 3 above). Note that the relayed channel may or may not be re-encrypted, depending on the mode of the attack. (relay) Finally the attacker’s browser can send N.B. back to W , trading it in for the session cookie cue they want (see steps 4 and 5 above).

BOW: The details of how an attacker might relay a visual code and convince a user o scan it with their visual code scanner device are given below. None of these attacks involve the attacker modifying the contents of any visual coded , only relaying them to trick victims into authenticating sessions they did not intend to. We show how two well-known types of attacks, pushing and mafia fraud, are even more insidious when applied to visual code authentication schemes.

Perhaps surprisingly, proponents of several of the schemes surveyed claim that resilience to pushing is one of their key security benefits; moreover, the usability-Dependability-security evaluation framework [3] for web authentication schemes does not penalize schemes that are only vulnerable to more elaborate real-time man-in-the-middle or relay attacks (cuff. The definition of its Resilient-pushing benefit). However, while this definition is appropriate for the schemes presented in Bandeau et al. ‘s evaluation, it fails to tell the whole story for visual code authentication schemes. 3. Pushing with visual codes In a traditional pushing attack, the victim unwittingly divulges their password to an attacker, who pretends to be or represent a website the victim trusts. The use of a scanner appears to offer some protection against pushing cause the secrets used to authenticate the user are contained within the scanner and are unknown to the user and, depending on the specific authentication protocol, might even never leave the scanner. While these secrets can be revealed by physically compromising the device, this is an altogether different type of attack which doesn’t scale.

An attacker can only physically compromise a single device 7 It would still be prudent to sign the contents of visual codes to prevent such attacks. At a time, with significant effort, rather than attack many of them in parallel over the net. However, an attacker is able to convince the victim to use their scanner and an attacker is able to relay a specific visual code over various communications channels, including email. For example, the attacker could send an email to the victim, purporting to be from their bank, claiming they need to scan a code to “validated?’ their scanner.

When the victim does so, they authenticate the nonce in the visual code which the attacker knows and relayed (see BIB above), and the attacker can now trade this nonce in for the users session cookie. (We might view this as an instance of the “chosen protocol attack” 13]. ) A visual code pushing email may come with the USUal carrots (“you will be entered into a prize draw’) and sticks (our account may be locked”) to persuade the victim to comply. However, there are several reasons why it would be more difficult for a user to spot a visual code pushing attempt, making the new attack more insidious.

In a traditional pushing attack, the victim must either reply to the attacker’s email, in which case the attacker must disclose an email address they control; or the victim must enter their password into a form on a fake version of the trusted website, which the attacker must provide. With a visual code pushing attack, neither is required of the attacker: the victim can scan the visual code right in their email client, thus contacting the legitimate website directly, and needn’t reply to the attacker in any other way.

By the same token, no “suspicious address” (email or web) will be found in the email that an alert user could spot to detect the fraud. Furthermore, it is important to see that the victim’s scanner also does not contact any server controlled by the attacker; the scanner really does authenticate to the website the fisherman is impersonating. If the scanner prompted the user for confirmation before each authentication, it would still not defend against this type of attack because the website identified by the visual code and contacted by the scanner for authentication is “correct”; the victim wants to authenticate to it.

Any existing training the user may have received, to check for the right website address or the HTTPS padlock, is useless here, even if followed to the letter. In light of this attack, the only advice that users could be given is that they should never scan a visual code contained in an out-of-band communication, such as an email, and they should only scan visual codes found on websites that they trust. But it is well known that reliably authenticating the website to the user is a hard, unsolved problem.