Category Archives: Authentication

Pico part II: What’s wrong with QR code password replacement schemes, and how to fix them!

Users don’t want to authenticate, they want to do useful or enjoyable things like sending emails, ordering groceries or playing games. To alleviate the burden of having to type passwords, Pico and several other schemes, such as SQRL and tiQR, let the user simply scan a QR code; then a cryptographic protocol authenticates the user behind the scenes and initiates a session. But users, unless they are on the move, may prefer to run their email or web browsing sessions on their full-size computer instead of on their  smartphone, whose user interface is relatively limited. Therefore they don’t want an authenticated session between their smartphone and the website but between their computer and the website, even if it’s the smartphone that scans the QR code.

In the original 2011 Pico paper (footnote 37), the website kept track of which “page impression” from a web browser was related to which Pico authentication by including a nonce in each login page QR code and having the Pico sign and return it as part of the authentication. Since then, within the Pico team, there has been much discussion of the so-called Page Impression Nonce or PIN, infamous both for the attacks it enables and its unfortunate, overloaded acronym. While other schemes may have called it something different, or not called it anything at all, it was always present in one form or another because they all used it to solve this same problem of linking browser sessions to authentications.

For example, in the SQRL system each QR code contains a URL, part of which is a random nonce (the PIN in this system). The SQRL app must sign and return this URL, thus associating the nonce with the app’s per-verifier public key. The web browser then starts its session by making another request which includes the URL (and thus the PIN) and gets back a session cookie.

So what’s the problem?

The problem with this kind of mechanism is that anyone else who learns the PIN can also make that second request, thus logging themselves in as the user who scanned the QR code. For example, a bad guy can obtain a QR code and its PIN from the login page of and display it somewhere, like the login page of, for a victim to scan. Now, assuming the victim had an account at, the attacker obtains a session that the victim unsuspectingly initiated with their smartphone.

Part of the problem is that QR codes are not human-readable. Some have suggested that a simple confirmation step (“Do you really want to login to”) might prevent such attacks, but we decided this wasn’t really good enough from a security or a usability perspective. We don’t want users to have to read the confirmation dialog and press the OK button every time they authenticate, and realistically they won’t, especially if they never normally do anything other than press OK.

Moreover, the confirmation step doesn’t help at all when the relaying of the QR code is combined with traditional phishing techniques. Consider receiving this email:

Subject: Urgent: Account security threat
Dear Customer

<compelling phishing mumbo jumbo>

To keep your account secure, please scan this QR code:

<login QR code with PIN known by the sender>

Kind regards,

Account security department

and if you oblige:

Do you really want to login to

Now the poor user thinks “Well yes, I do, that’s exactly what the account security team asked me to do” and even worse: “I’m definitely not being phished, I remember what those security people kept telling me about checking the address of the website before logging in”.

How to fix it

The solution we came up with is called session delegation. Instead of having a nonce in each QR code, which anyone can later trade-in for an authenticated session, we have the website return a session delegation token to the Pico (not the web browser) as part of the authentication protocol. The Pico may then delegate the session to the browser on the bigger computer by sending it this token, via a secure channel. (For further details see section 4.1 of our “lousy phish” paper.) The price to pay for this strategy is that it requires a channel from the Pico to the browser, which is much harder to provide than the one in the opposite direction (the visual “QR code” channel).

We made a prototype which used Bluetooth for the delegation channel but, because Bluetooth was sometimes difficult to set up and not universally available, we even thought about using an audio cable plugged into the microphone jack of the computer. However, we were still worried about the availability and usability of these hardware-based solutions. We did a lot of research into NAT and firewall traversal techniques (such as STUN and TURN) to see if we could use peer-to-peer IP connectivity, but this is not possible in all cases without a separate signalling channel. In our latest prototype we’re using a “rendezvous point”, which is a very simple relay server we’ve designed, running in the public Internet. The rendezvous point is the most universal and usable solution, but does come with some privacy concerns, namely that the untrusted rendezvous server gets to see the Pico/computer IP address pairs which are communicating. So we still allow privacy-conscious users to adopt less convenient alternatives if they’re willing to pay the price of setting up Bluetooth, connecting cables or changing their firewall/NAT settings, but we don’t impose that cost on everyone.

The drawback of this approach is that the user’s computer requires some Pico software to receive the delegation tokens, via the rendezvous point or whatever other channel. Having to install these hurts the “deployability” of the system as a whole and could render it completely useless in situations where installing new software is not possible. But another innovation, making the delegation token take the form of a URL, means there is always a last-resort fallback channel: manual transcription. If a Pico user can’t install the software on, or doesn’t want to trust, a particular computer, they can always still retype the token URL. There are other security concerns related to having URLs which will log your browser into someone else’s account, but you’ll have to read the lousy phish paper for a more detailed discussion of this topic.

There is clearly much interest in finding a replacement for passwords and several schemes (such as US 8261089 B2Snap2Pass, tiQR, US 20130219479 A1, QRAuth, SQRL) propose using QR codes. But upon close inspection, all of the above use a page impression nonce, making them vulnerable to session hijacking attacks. We rejected the idea that this could be solved simply by getting the user to carry out more checks and instead we propose an architectural fix which provides a more secure basis for the design of Pico.

For more information about Pico, have a look at our website, sign up to our mailing list and stay tuned for more Pico-related posts on Light Blue Touchpaper in the near future.

Pico part I: Russian hackers stole a billion passwords? True or not, with Pico you wouldn’t worry about it.

In last week’s news (August 2014) we heard that Russian hackers stole 1.2 billion passwords. Even though such claims sound somewhat exaggerated, and not correlated with a proportional amount of fraudulent access to user accounts, password compromise is always a pain for the web sites involved—more so when it causes direct reputation damage by having the company name plastered on the front page of the Financial Times, as happened to eBay on 22 May 2014 after they lost to cybercriminals the passwords of over 100 million users. Shortly before that, in April 2014, it was the Heartbleed bug that forced password resets on allegedly 66% of all websites. And last year, in November 2013, it was Adobe who lost the passwords of 150 million users. Keep going back and you’ll find many more incidents. With alarming frequency we hear of some major security exploit that compromises an enormous number of passwords and embarrasses web sites into asking their users to pick a new password.

Note the irony: despite the complaints from some arrogant security experts that users are too lazy or too dumb to pick strong passwords, when such attacks take place, all users must change their passwords, not just those with a weak one. Even the diligent users who went to the trouble of following complicated instructions and memorizing “avKpt9cpGwdp”, not to mention typing it every day, are punished, for a sin they didn’t commit (the insecurity of the web site) just as much as the allegedly lazy ones who picked “p@ssw0rd” or “1234”. This is fundamentally unfair.

My team has been working on Pico, an ambitious project to replace passwords with a fairer system that does not require remembering secrets. The primary goal of Pico is to be easier to use than remembering a bunch of PINs and passwords; but, incidentally, it’s also meant to be much more secure. On that note, because Pico uses public key cryptography, if a Pico-based web site is compromised, then its users do not need to change their login credentials. The attackers can only steal the users’ public keys, not their private keys, and therefore are not able to impersonate them, neither at that site nor anywhere else (besides the fact that, to protect your privacy, your Pico uses a different key pair for every one of your accounts). This alone, even aside from any usability improvements, should be a good enough reason for web sites to convert to Pico.

We didn’t blog it then, but a few months ago we produced a short introductory video of our vision for Pico. On the Pico web site, besides that video and others, there are also frequently asked questions and, for those wanting to probe more deeply, a growing collection of technical papers.


This is the first part in a series on the Pico project: my research associates will follow it up with further developments. Pico was recently featured in The Observer and on Sophos’s Naked Security blog, and is about to feature on BBC Radio 4’s PM programme on Tuesday 19 August at 17:00 (broadcast on Thursday 21 August 2014, with a slight cut; currently on iPlayer, starting at 46:28 . Full version broadcast on BBC World Service and downloadable, for a while, from the BBC Global News Podcast, starting at 21:37 ).

Update: the Pico web site now has a page with press coverage.

Light Blue Touchpaper now on HTTPS

Light Blue Touchpaper now supports TLS, so as to protect passwords and authentication cookies from eavesdropping. TLS support is provided by the Pound load-balancer, because Varnish (our reverse-proxy cache) does not support TLS.

The configuration is intended to be a reasonable trade-off between security and usability, and gets an A– on the Qualys SSL report. The cipher suite list is based on the very helpful Qualys Security Labs recommendations and Apache header re-writing sets the HttpOnly and Secure cookie flags to resist cookie hijacking.

As always, we might have missed something, so if you notice problems such as incompatibilities with certain browsers, then please let us know on <>. or in the comments.

Financial cryptography 2014

I will be trying to liveblog Financial Cryptography 2014. I just gave a keynote talk entitled “EMV – Why Payment Systems Fail” summarising our last decade’s research on what goes wrong with Chip and PIN. There will be a paper on this out in a few months; meanwhile here’s the slides and here’s our page of papers on bank security.

The sessions of refereed papers will be blogged in comments to this post.

Anatomy of Passwords

Passwords have not really changed since they were first used. Let’s go down the memory lane a bit and then analyse how password systems work and how they could be improved. You may say – forget passwords, OTP is the way forward. My next question would then be: So why do we use OTP in combination with passwords, when they are so good?
Continue reading Anatomy of Passwords

NSA Award for Best Scientific Cybersecurity Paper

Yesterday I received the NSA award for the Best Scientific Cybersecurity Paper of 2012 for my IEEE Oakland paper “The science of guessing.” I’m honored to have been recognised by the distinguished academic panel assembled by the NSA. I’d like to again thank Henry Watts, Elizabeth Zwicky, and everybody else at Yahoo! who helped me with this research while I interned there, as well as Richard Clayton and Ross Anderson for their support and supervision throughout.

On a personal note, I’d be remiss not to mention my conflicted feelings about winning the award given what we know about the NSA’s widespread collection of private communications and what remains unknown about oversight over the agency’s operations. Like many in the community of cryptographers and security engineers, I’m sad that we haven’t better informed the public about the inherent dangers and questionable utility of mass surveillance. And like many American citizens I’m ashamed we’ve let our politicians sneak the country down this path.

In accepting the award I don’t condone the NSA’s surveillance. Simply put, I don’t think a free society is compatible with an organisation like the NSA in its current form. Yet I’m glad I got the rare opportunity to visit with the NSA and I’m grateful for my hosts’ genuine hospitality. A large group of engineers turned up to hear my presentation, asked sharp questions, understood and cared about the privacy implications of studying password data. It affirmed my feeling that America’s core problems are in Washington and not in Fort Meade. Our focus must remain on winning the public debate around surveillance and developing privacy-enhancing technology. But I hope that this award program, established to increase engagement with academic researchers, can be a small but positive step.

Should we boycott John Lewis?

Last weekend, my wife and I were in Milton Keynes where we bought a cradle as a present for our new granddaughter. They had only the demo model in the shop, but sold us one to pick up from their store in Cambridge. So yesterday I went into John Lewis with the receipt, to be told by the official that as I couldn’t show the card with which the purchase was made, they needed photo-id. I told him that along with over a million others I’d resisted the previous government’s ID card proposals, the last government had lost the election, and I didn’t carry ID on principle. The response was the usual nonsense: that I should have read the terms and conditions (but when I studied the receipt later it said nothing about ID) and that he was just doing his job (but John Lewis prides itself on being employee-owned, so in theory at least he is a partner in the firm). I won’t be shopping there again anytime soon.

We get harassed more and more by security theatre, by snooping and by bullying. What’s the best way to push back? Why can businesses be so pointlessly annoying?

Perhaps John Lewis are consciously pro-Labour given their history as a co-op; but it’s not prudent to advertise that in a three-way marginal like Cambridge, let alone in the leafy southern suburbs where they make most of their money. Or perhaps it’s just incompetence. When my wife phoned later to complain, the customer services people apologised and said we should have been told when we bought the thing that we’d need to show ID. She offered to post the cradle to our daughter, but then rung back later to say they’d lost the order and would need our paperwork. So that’s another 30-mile round-trip to their depot. But if they’re incompetent, why should I trust them enough to buy their food?

I invite the chairman, Charlie Mayfield, to explain by means of a follow-up to this post whether this was policy or cockup. Will he continue to demand photo-id even from customers who have a principled objection? Will he tell us who in the firm imposed this policy, and show us the training material that was prepared to ensure that counter staff would explain it properly to customers?