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.
What is the communication channel between the Pico device and, say, the PC I use to log onto a website?
Input is by QR Code but how is the response sent back?
We have been experimenting with various implementation options, which involve different trade-offs.
One is to use a local radio channel such as Bluetooth. The main downside at the moment is the additional management burden imposed on the user to set it up (including key management), plus the fact that your desktop PC may not support it yet. These problems may become less serious in the future if Bluetooth becomes more successful. A local radio channel is also useful for other things Pico wants to do, so we’ll continue to pursue this option.
A cute/horrible hack around the deployment problems of Bluetooth is to use an external IP rendezvous point. The main downsides are privacy (even though, in theory, privacy geeks like us could run their own private rendezvous point; but that’s not viable for normal people so we have to do better) and availability, i.e. depending on additional in-cloud infrastructure that may or may not be up. This isn’t the long term solution for Pico but gets us going in the meantime, at least for user trials, when we can’t use a local radio channel.
Many similar systems avoid using a return channel from the QR-code-scanning device to the PC with the browser precisely because it’s so hard to provide one in practice. We believe this is an architectural mistake that opens up security flaws. One of my colleagues is going to say quite a bit more about this in a future installment in this series.
As long as the system requires some sort of hardware installation on the PC, doesn´t that severely limit the userbase, mainly to closed systems?
What if I set up my GMail to log in with Pico, I could never access my email from some other PC on the road which doesn´t have some radio hardware installed?
Yes: obviously anything that requires specific hardware on the computer will limit deployability. From a research viewpoint it’s fine to assume that we’ll have universal short-range radio connectivity between devices in the future; but in practice that’s why we also came up with a workaround (the rendezvous point) that doesn’t require extra hardware.
Do you know when the Radio 4 programme will air?
Not yet. When I do, I’ll update this post. The reporter is coming here today to record it. After their editing, I don’t expect we’ll get more than a few minutes of airtime within the one-hour programme, so I imagine there won’t be scope to go into a lot of geeky technical detail. See the papers on the mypico.org web site for that.
I presume the recording will then be available on iplayer, at least for a while.
He said it’s scheduled for Tuesday, but cautioned that schedules may change.