I’m at the 23rd Security Protocols Workshop, whose theme this year is is information security in fiction and in fact. Engineering is often inspired by fiction, and vice versa; what might we learn from this?
I will try to liveblog the talks in followups to this post.
I will be trying to liveblog Financial Cryptography 2015.
The opening keynote was by Gavin Andresen, chief scientist of the Bitcoin Foundation, and his title was “What Satoshi didn’t know.” The main unknown six years ago when bitcoin launched was whether it would bootstrap; Satoshi thought it might be used as a spam filter or a practical hashcash. In reality it was someone buying a couple of pizzas for 10,000 bitcoins. Another unknown when Gavin got involved in 2010 was whether it was legal; if you’d asked the SEC then they might have classified it as a Ponzi scheme, but now their alerts are about bitcoin being used in Ponzi schemes. The third thing was how annoying people can be on the Internet; people will abuse your system for fun if it’s popular. An example was penny flooding, where you send coins back and forth between your sybils all day long. Gavin invented “proof of stake”; in its early form it meant prioritising payers who turn over coins less frequently. The idea was that scarcity plus utility equals value; in addition to the bitcoins themselves, another scarce resources emerges as the old, unspent transaction outputs (UTXOs). Perhaps these could be used for further DoS attack prevention or a pseudonymous identity anchor.
It’s not even clear that Satoshi is or was a cryptographer; he used only ECC / ECDSA, hashes and SSL (naively), he didn’t bother compressing public keys, and comments suggest he wasn’t up on the latest crypto research. In addition, the rules for letting transactions into the chain are simple; there’s no subtlety about transaction meaning, which is mixed up with validation and transaction fees; a programming-languages guru would have done things differently. Bitcoin now allows hashes of redemption scripts, so that the script doesn’t have to be disclosed upfront. Another recent innovation is using invertible Bloom lookup tables (IBLTs) to transmit expected differences rather than transmitting all transactions over the network twice. Also, since 2009 we have FHE, NIZLPs and SNARKs from the crypto research folks; the things on which we still need more research include pseudonymous identity, practical privacy, mining scalability, probabilistic transaction checking, and whether we can use streaming algorithms. In questions, Gavin remarked that regulators rather like the idea that there was a public record of all transactions; they might be more negative if it were completely anonymous. In the future, only recent transactions will be universally available; if you want the old stuff you’ll have to store it. Upgrading is hard though; Gavin’s big task this year is to increase the block size. Getting everyone in the world to update their software at once is not trivial. People say: “Why do you have to fix the software? Isn’t bitcoin done?”
I’ll try to blog the refereed talks in comments to this post.
We are asked to remember far too many passwords. This problem is most acute on the web. And thus, unsurprisingly, it is on the web that technical solutions have had most success in replacing users’ ad hoc coping strategies. One of the longest established and most widely adopted technical solutions is a password manager: software that remembers passwords and submits them on the user’s behalf. But this isn’t as straightforward as it sounds. In our recent work on bootstrapping adoption of the Pico system [1], we’ve come to appreciate just how hard life is for developers and maintainers of password managers.
In a paper we are about to present at the Passwords 2014 conference in Trondheim, we introduce our proposal for Password Manager Friendly (PMF) semantics [2]. PMF semantics are designed to give developers and maintainers of password managers a bit of a break and, more importantly, to improve the user experience.
Imagine, somewhere in the internet that no-one trusts, there is a piece of hardware, a small computer, that works just for you. You can trust it. You can depend on it. Things may get rough but it will stay there to get you through. That is Nikka, it is the fixed point on which you can build your security and trust. [Now as a Kickstarter project]
You may remember our proof-of-concept implementation of a password protection for servers – Hardware Scrambling (published here in March). The password scrambler was a small dongle that could be plugged to a Linux computer (we used Raspberry Pi). Its only purpose was to provide a simple API for encrypting passwords (but it could be credit cards or anything else up to 32 bytes of length). The beginning of something big?
It received some attention (Ars Technica, Slashdot, LWN, …), certainly more than we expected at the time. Following discussions have also taught us a couple of lessons about how people (mostly geeks in this contexts) view security – particularly about the default distrust expressed by those who discussed articles describing our password scrambler.
We eventually decided to build a proper hardware cryptographic platform that could be used for cloud applications. Our requirements were simple. We wanted something fast, “secure” (CC EAL5+ or even FIPS140-2 certified), scalable, easy to use (no complicated API, just one function call) and to be provided as a service so no-one has to pay upfront the price of an HSM if they just want to have a go at using proper cryptography for their new or old application. That was the beginning of Nikka.
This is our concept: Nikka comprises a set of powerful servers installed in secure data centres. These servers can create clusters delivering high-availability and scalability for their clients. Secure hardware forms the backbone of each server that provides an interface for simple use. The second part of Nikka are user applications, plugins, and libraries for easy deployment and everyday “invisible” use. Operational procedures, processes, policies, and audit logs then guarantee that what we say is actually being done.
We have been building it for a few months now and the scalable cryptographic core seems to work. We have managed to run long-term tests of 150 HMAC transactions per second (HMAC & RNG for password scrambling) on a small development platform while fully utilising available secure hardware. The server is hosted at ideaSpace and we use it to run functional, configuration and load tests.
We have never before designed a system with so many independent processes – the core is completely asynchronous (starting with Netty for a TCP interface) and we have quickly started to appreciate detailed trace logging we’ve implemented from the very beginning. Each time we start digging we find something interesting. Real-time visualisation of the performance is quite nice as well.
Nikka is basically a general purpose cryptographic engine with middleware layer for easy integration. The password HMAC is this time used only as one of test applications. Users can share or reserve processing units that have Common Criteria evaluations or even FIPS140-2 certification – with possible physical hardware separation of users.
If you like what you have read so far, you can keep reading, watching, supporting at Kickstarter. It has been great fun so far and we want to turn it into something useful in 2015. If it sounds interesting – maybe you would like to test it early next year, let us know! @DanCvrcek
A light-hearted look at the ideas presented a couple of weeks ago in a paper at the UPSIDE workshop in Seattle.
One of the problems inherent in boldly going where no man has gone before is that, more often than you might imagine, you may be required to blow up the spaceship on which you’re travelling. James T Kirk was forced to do this at least once, and he and his successors came perilously close to it on several other occasions.
But who gets to make this decision? Given the likelihood that some members of the crew may be possessed by alien life-forms at the time, it seems unwise to leave such decisions to any single individual, even if he’s the captain. And you also can’t require any specific other staff-member to back him up, since they may have had to sacrifice themselves earlier for the good of the many. Auto-destruct sequences, therefore, can typically only be initiated when any three senior officers agree and give their secret passwords.
It is a wonderful sign of the times that, when the first Star Trek episode in which this happens was broadcast in 1969, the passwords required to detonate a spaceship with 400 passengers on board were noticeably weaker than those now required to log in to a typical Kickstarter project.
Secret sharing – background
Some of the most beautiful examples, I believe, of using a simple, readily-understandable idea to solve a complex problem can be found in the secret-sharing systems proposed almost simultaneously by Adi Shamir and George Blakley, way back in 1979. These are just the sort of thing you need to need to control self-destruct sequences, and are certainly better than the four-character passwords used by Kirk and Scotty.
Most readers of LBT will be familiar with this, but in case you aren’t, the underlying concept is to encode the secret you need to protect – for example, the auto-destruct code – as the coefficients of a particular quadratic equation. If you know any three points on the curve, you can deduce the underlying equation. So all you have to do is give each of Kirk, Scotty, Spock and Bones the coordinates of a point, and any three of these ’shares’ can then unlock the secret which will trigger the detonation. If you want to insist on four or more officers, you use a higher-order polynomial. This is Shamir’s algorithm; Blakley’s is similar, but whichever you use, there is, I think, a real elegance in solving a difficult technical problem using a concept that can be explained in a paragraph to anyone with high-school level maths.
A somewhat more down-to-earth example of its use can be found in the DNSSEC system used to secure the core servers of the DNS, on which so much of the internet depends. The master key needed to reset this, in the event of some global calamity, is divided up between seven keyholders based in different countries. One of them told me over a beer recently that it required any five of them to get together in the US to be able to reconstruct the system.
PICO
In the Pico project (see earlier posts), we’re exploring the same secret-sharing concepts but at a personal rather than a global or galactic level.
The idea is that your Pico device, which provides authentication on your behalf to a wide variety of systems, should only be able to do so when it is confident that you are present. There are several ways it might detect that – biometrics perhaps being the most obvious – but we wanted a system that would be completely automatic, continuous and non-intrusive: it wouldn’t require you to re-scan your retina every few minutes, for example.
So the Pico assumes that you are present only if it can detect, nearby, a sufficient number of other devices that you normally carry. These ‘Picosiblings’ may be special devices dedicated to this purpose – bluetooth-enabled cufflinks or earrings, for example – or the Picosibling functionality may be built into phones, smart watches, laptops and car key-fobs. But, together, a sufficient number of them constitute an ‘aura’ of safety in which the Pico feels comfortable about releasing your credentials when you use it to log in.
You could just program the Pico to make this decision, but a more secure approach is to use secret-sharing. Your Pico stores your credentials in encrypted form, and the Picosiblings actually enable it by each giving up a share of the secret used to do the encryption. Since this information is not cached, even the Pico cannot decide to expose the information when you are not around.
Some challenges
This basic Picosibling concept is not bad, but can we improve it? How well can we model real-world user behaviour using these ideas? Where might they fall down, and do we need to invent anything new to deal with the edge cases? And can it help us make better decisions about when to blow up a starship?
Let’s consider some scenarios.
1. My Precious
My car keys are with me about 30% of the time, and may occasionally be with someone else. My wedding ring, on the other hand, has been a 100% reliable indicator of my presence for the last 23 years. (It’s too bad my wife didn’t give me a Bluetooth-enabled one.) We all have different possessions which may be more or less reliable indicators that we are around, and we can represent this by giving them different numbers of shares. Most of my Picosiblings might have one share, but my wallet and phone might have two, and my wedding ring four. If my ring is absent, you’ll need significantly more confirmation from other sources, in the same way that you might need disproportionately more senior officers if the captain is absent.
2. Smarter Picosiblings
Is my watch a good indicator of my presence? Well, yes, when it’s with me, but not when it’s sitting on my bedside table. There may be occasions when Picosiblings are more or less confident that you are present. So we can give each sibling a certain number of shares, but it may not choose to release them to the Pico in all situations. A sibling that detects and recognises your heartbeat might give out differing numbers of its shares based on how confident it is about its recognition. Something you normally wear or carry might include an accelerometer, and give out fewer shares if it hasn’t moved in the last few minutes. The number of shares might decay over time, as the device gets further from the moment at which it was confident of your presence, so a fingerprint sensor might be sufficient to unlock your Pico on its own, if you’ve used it in the last ten seconds. Another metric might be proximity: if the Picosibling could detect the Pico was close by, it might be willing to hand over more shares than if it were on the other side of the room.
3. The trouble with Klingons
But suppose we need something more sophisticated than simply the raw number of shares to unlock the secret? If your starship has a large number of Klingon officers, who place a high value on dying honourably in battle, you might wish to insist that at least two races were involved in any major decision like this.
Fortunately we don’t need a new mechanism: we can just use our current system twice over. We split the core secret into several shares: one for humans, one for Vulcans, one for Klingons, one for Betazoids. Each of those shares can then be subdivided in the same way for the individuals concerned. Two or more Vulcans are needed to reconstruct the Vulcan share, and two or more such species actually to blow up the ship.
In the Pico world, suppose your shoes are all Picosiblings. If you have many pairs of shoes, someone entering your bedroom may find they have plenty of shares even if you aren’t around. We can use this method of creating ‘categories of shares’ to limit the effect that a particular class of device can have, to ensure that shoes alone can never be sufficient to do the unlocking.
4. Greater than the sum of its parts
Suppose my my car, my car keys, and my house keys are all Picosiblings, and they each have one share. Anyone inside my car is likely to have my car keys, including a thief who has just found them on the pavement. But we could reasonably argue that someone who is inside my car and has my house keys is more likely to be me; that a stranger is less likely to have this particular combination of Picosiblings, and so their conjunction should be worth more than might be indicated by a simple addition of their values.
We can achieve this in various ways; a simple approach is just to cut a share in half and give one half to each sibling. These would be sent to the Pico along with the complete shares, and if it receives matching halves from two devices, it would be able to construct extra shares which correspond to the value of their relationship.
5. You can’t take that away from me
Here’s a challenge for readers. Can you think of a good way to implement negative shares? Let me explain…
Suppose you are in an airport check-in queue and a significant number of your worldly possessions are in the suitcase beside you. Someone who pinches your Pico from your pocket will have plenty of shares accessible either by standing behind you, or by getting close to your suitcase at some later point in the baggage-handling process. Travelling is one of those situations when you might feel a bit vulnerable and so require more confirmation of your presence than you would in your home country. If your suitcase could emit negative shares, then it would raise the threshold of affirmation needed by your Pico when it was around.
There are many challenges here, both technical and practical: for example, anyone who knows that there is a negative influence nearby may be able to remove it, e.g. by tipping the items out of the suitcase. But it would at least deter subtle unobserved attacks in the check-in queue. It would be good if observers, and ideally the Pico itself, could not distinguish positive from negative shares except with regards to their final effect. And so on. As I said: a challenge for the reader!
Sharing options
So we’ve introduced several ideas which can help with some real-life scenarios, yet they’re all based on the same simple secret-sharing concept:
Extending the tree
Let me finish with one last question. To what extent are Picos and Picosiblings fundamentally different? Picos gain confidence to submit your credentials to a service based on the reassurance they get from Picosiblings. But we’ve also discussed the idea of Picosiblings getting confidence to submit their shares to a Pico based on other factors in the environment. Perhaps we could extend this hierarchy in the other direction, too.
A company might need k-of-n shares from the major investors’ Picos to appoint their representative director to the board. The company Pico might then need k-of-n of the directors’ Picos to authorise a major decision or transaction. And a commercial building might need k-of-n of the companies’ boards to agree to the resurfacing of the parking lot. This could be extended to political, national, even global decisions.
Perhaps I’m pushing the simple secret-sharing concept too far. But at the very least it’s an interesting thought experiment to consider how much we can represent real-world situations with this one idea.
After all, we need a simple, reliable and secure way to make these decisions in our own back yard, before we start interacting with the rest of the universe.
Many users are willing to sacrifice some security to gain quick and easy access to their services, often in spite of advice from service providers. Users are somehow expected to use a unique password for every service, each sufficiently long and consisting of letters, numbers, and symbols. Since most users do not (indeed, cannot) follow all these rules, they rely on unrecommended coping strategies that make passwords more usable, including writing passwords down, using the same password for several services, and choosing easy-to-guess passwords, such as names and hobbies. But usable passwords are not secure passwords and users are blamed when things go wrong.
This isn’t just unreasonable, it’s unjustified, because even secure passwords are not immune to attack. A number of security breaches have had little to do with user practices and password strength, such as the Snapchat hacking incident, theft of Adobe customer records and passwords, and the Heartbleed bug. Stronger authentication requires a stronger and more usable authentication scheme, not longer and more complex passwords.
We have been evaluating the usability of our more secure, token-based system: Pico, a small, dedicated device that authenticates you to services. Pico is resistant to theft-resistant because it only works when it is close to its owner, which it detects by communicating with other devices you own – Picosiblings. These devices are smaller and can be embedded in clothing and accessories. They create a cryptographic “aura” around you that unlocks Pico.
For people to adopt this new scheme, we need to make sure Pico is psychologically acceptable – unobtrusive and easily and routinely used, especially relative to passwords. The weaknesses of passwords have not been detrimental to their ubiquity because they are easy to administer, well understood, and require no additional hardware or software. Pico, on the other hand, is not currently easy to administer, is not widely understood, and does require additional hardware and software. The onus is on the Pico team to make our solution convenient and easy to use. If Pico is not sufficiently more convenient to use than passwords, it is likely to be rejected, regardless of improvements to security.
This is a particular challenge because we are not merely attempting to replace passwords as they are supposed to be used but as they are actually used by real people, which is more usable, though much less secure, than our current conception of Pico.
Small electronic devices worn by the user – typically watches, wristbands, or glasses – have had limited success (e.g. Rumba Time Go Watch and the Embrace+ Wristband). Reasons include issues with the accuracy of the data they collect, time spent having to manage data, the lack of control over appearance, the sense that these technologies are more gimmicks than useful, the monetary cost, and battery life (etc.). All of these issues need to be carefully considered to pass the user’s cost-benefit analysis of adoption.
To ensure the psychological acceptability of Pico, we have been conducting user studies from the very early design stages. The point of this research is to make sure we don’t impose any restrictive design decisions on users. We want users to be happy to adopt Pico and this requires a user-centred approach to research and development based on early and frequent usability testing.
Thus far, we have qualitatively investigated user experiences of paper prototypes of Pico, which eventually informed the design of three-dimensional plastic prototypes (Figure 1).
This exploratory research provided insight into whether early Pico designs were sufficient for allowing the user to navigate through common authentication tasks. We then conducted interviews with these plastic prototypes, asking participants which they preferred and why. In the same interviews, we presented participants with a range of pseudo-Picosiblings (Figure 2) to get an idea of the feasibility of Picosiblings from the enduser’s perspective.
The challenge seems to be in finding a balance between cost, style, and usefulness. Consider, for example, the usefulness of a watch. While we expect a watch to tell us the time (to serve a function), what we really care about is its style and cost. This is the difference between my watch and your watch, and it is where we find its selling power. Most wearable electronic devices, such as smart-watches and fitness gadgets, advertise function and usefulness first, and then style, which is often limited to one, or maybe two, designs. And cost? Well, you’ll just have to find a way to pay for it. Pico, like these devices, could provide the potential usefulness required for widespread and enduring adoption, which, if paired with low cost and user style, should have a greater degree of success than previous wearable electronic devices.
Initial analysis of the results reveals polarised opinions of how Pico and Picosiblings should look, from being fashionable and personalizable to being disguised and discrete. Interestingly, users seemed more concerned about the security of Pico than about the security of passwords. Generally, however, the initial research indicates that users do see the usefulness of Pico as a standalone device, providing it is reliable and can be used for a wide range of services; hardware is no benefit to people unless it replaces most, if not all, passwords, otherwise it becomes another thing that people have to remember.
A legitimate concern for users is loss or theft; we are working to ensure that such incidents do not cause inconvenience or pose threat to the user by making the system easily recoverable. Related concerns relevant to possessing physical devices are durability, physical ease-of-use, the awkwardness of having to handle and aim the Pico at a QR code, and the everyday convenience of remembering and carrying several devices.
To make remembering and carrying several devices easier and more worthwhile, interviews revealed that Picosiblings should have more than one function (e.g. watches, glasses, ID cards). By making Picosiblings practical, users are more likely to remember to take them, and to perceive the effort of carrying them around as being outweighed by the benefit. Typically, 3-4 items were the maximum number of Picosiblings that users said they would be happy to carry; the aim would be to reduce the required number of Picosiblings to 1 or 2 (depending on what they are), allowing users to carry more on them as “backups” if they were going to use them anyway.
Though suggested by some, the same emphasis on dual-function was not observed for Pico, since this device serves a sufficiently valuable function in itself. However, while many found it perfectly reasonable to carry a dedicated, secure device (given its function), some did express a preference for the convenience of an App on their smartphone. To create a more streamlined experience, we are currently working on such an App, which should give these potential Pico users the flexibility they seem to desire.
By taking into account these and other user opinions before committing to a single design and implementation, we are working to ensure Pico isn’t just theoretically secure – secure only if we can rely on users to implement it properly despite any inconvenience. Instead, we can make sure Pico is actually secure, because we will be creating an authentication scheme that requires users to do only what they would do (or better, want to do) anyway. We can achieve this by taking seriously the capabilities and preferences of the end-user.
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.
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 bank.com and display it somewhere, like the login page of randomgameforum.com, for a victim to scan. Now, assuming the victim had an account at bank.com, the attacker obtains a bank.com 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 bank.com?”) 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:
From: security@bank.com
To: victim@example.com
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 departmentand if you oblige:
Do you really want to login to bank.com?
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”.
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 B2, Snap2Pass, 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.
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 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 <lbt-admin
I’m at the IEEE Symposium on Security and Privacy, known in the trade as “Oakland” even though it’s now moved to San Jose. It’s probably the leading event every year in information security. I will try to liveblog it in followups to this post.