Using a multi-word “passphrase” instead of a password has been suggested for decades as a way to thwart guessing attacks. The idea is now making a comeback, for example with the Fastwords proposal which identifies that mobile phones are optimised for entering dictionary words and not random character strings. Google’s recent password advice suggests condensing a sentence to form a password, while Komanduri et al.’s recent lab study suggests simply requiring longer passwords may be the best security policy. Even xkcd espouses multi-word passwords (albeit with randomly-chosen words). I’ve been advocating through my research though that authentication schemes can only be evaluated by studying large user-chosens distribution in the wild and not the theoretical space of choices. There’s no public data on how people choose passphrases, though Kuo et al.’s 2006 study for mnemonic-phrase passwords found many weak choices. In my recent paper (written with Ekaterina Shutova) presented at USEC last Friday (a workshop co-located with Financial Crypto), we study the problem using data crawled from the now-defunct Amazon PayPhrase system, introduced last year for US users only. Our goal wasn’t to evaluate the security of the scheme as deployed by Amazon, but learn more how people choose passphrases in general. While this is a relatively limited data source, our results suggest some caution on this approach. Continue reading Some evidence on multi-word passphrases
Category Archives: Authentication
How hard are PINs to guess?
Note: this research was also blogged today at the NY Times’ Bits technology blog.
I’ve personally been researching password statistics for a few years now (as well as personal knowledge questions) and our research group has a long history of research on banking security. In an upcoming paper at next weel’s Financial Cryptography conference written with Sören Preibusch and Ross Anderson, we’ve brought the two research threads together with the first-ever quantitative analysis of the difficulty of guessing 4-digit banking PINs. Somewhat amazingly given the importance of PINs and their entrenchment in infrastructure around the world, there’s never been an academic study of how people actually choose them. After modeling banking PIN selection using a combination of leaked data from non-banking sources and a massive online survey, we found that people are significantly more careful choosing PINs then online passwords, with a majority using an effectively random sequence of digits. Still, the persistence of a few weak choices and birthdates in particular suggests that guessing attacks may be worthwhile for an opportunistic thief. Continue reading How hard are PINs to guess?
Observations from two weeks of SSH brute force attacks
Earlier this month, I blogged about monitoring password-guessing attacks on a server, via a patched OpenSSH. This experiment has now been running for just over two weeks, and there are some interesting results. I’ve been tweeting these since the start.
As expected, the vast majority of password-guessing attempts are quite dull, and fall into one of two categories. Firstly there are attempts with a large number of ‘poor’ passwords (e.g. “password”, “1234”, etc…) against a small number of accounts which are very likely to exist (almost always “root”, but sometimes others such as “bin”).
Secondly, there were attempts on a large number of accounts which might plausibly exist (e.g. common first names and software packages such as ‘oracle’). For these, there were a very small number of password attempts, normally only trying the username as password. Well established good practices such as choosing a reasonably strong password and denying password-based log-in to the root account will be effective against both categories of attacks. Surprisingly, there were few attempts which were obviously default passwords from software packages (but they perhaps were hidden in the attempts where username equalled password). However, one attempt was username: “rfmngr”, password: “$rfmngr$”, which is the default password for Websense RiskFilter (see p.10 of the manual).
There were, however, some more interesting attempts. Continue reading Observations from two weeks of SSH brute force attacks
Brute force password-guessing attempts on SSH
I recently set up a server, and predictably it started seeing brute-force password-guessing attempts on SSH. The host only permits public key authentication, and I also used fail2ban to temporarily block repeat offenders and so stop my logs from being filled up. However, I was curious what attackers were actually doing, so I patched OpenSSH to log the username and password for log-in attempts to invalid users (i.e. all except my user-account).
Some of the password attempts are predictable (e.g. username: “root”, password: “root”) but others are less easy to explain. For example, there was a log-in attempt for the usernames “root” and “dark” with the password “ManualulIngineruluiMecanic”, which I think is Romanian for Handbook of Mechanical Engineering. Why would someone use this password, especially for the uncommon username “dark”? Is this book common in Romania; is it likely to be by the desk of a sys-admin (or hacker) trying to choose a password? Has the hacker found the password in use on another compromised system; is it the default password for anything?
Over the next few weeks I’ll be posting other odd log-in attempts on my Twitter feed. Follow me if you would like to see what I find. Feel free to comment here if you have any theories on why these log-in attempts are being seen.
Want to create a really strong password? Don’t ask Google
Google recently launched a major advertising campaign around its “Good to Know” guides to online safety and privacy. Google’s password advice has appeared on billboards in the London underground and a full-page ad in The Economist. Their example of a “very strong password” is ‘2bon2btitq’, taken from the famous Hamlet quote “To be or not to be, that is the question”.
Empirically though, this is not a strong password-it’s almost exactly average! Continue reading Want to create a really strong password? Don’t ask Google
Pico: no more passwords (at Usenix Security)
The usability community has long complained about the problems of passwords (remember the Adams and Sasse classic). These days, even our beloved XKCD has something to say about the difficulties of coming up with a password that is easy to memorize and hard to brute-force. The sensible strategy suggested in the comic, of using a passphrase made of several common words, is also the main principle behind Jakobsson and Akavipat’s fastwords. It’s a great suggestion. However, in the long term, no solution that requires users to remember secrets is going to scale to hundreds of different accounts, if all those remembered secrets have to be different (and changed every couple of months).
This is why, as I previously blogged, I am exploring the space of solutions that do not require the memorization of any secrets—whether passwords, passphrases, PINs, faces, graphical squiggles or anything else. My SPW paper, Pico: No more passwords, was finalized in June (including improvements suggested in the comments to the previous blog post) and I am about to give an invited talk on Pico at Usenix Security 2011 in San Francisco.
Usenix talks are recorded and the video is posted next to the abstracts: if you are so inclined, you will be able to watch my presentation shortly after I give it.
To encourage adoption, I chose not to patent any aspect of Pico. If you wish to collaborate, or fund this effort, talk to me. If you wish to build or sell it on your own, be my guest. No royalties due—just cite the paper.
Make noise and whisper: a solution to relay attacks
About a moth ago I’ve presented at the Security Protocols Workshop a new idea to detect relay attacks, co-developed with Frank Stajano.
The idea relies on having a trusted box (which we call the T-Box as in the image below) between the physical interfaces of two communicating parties. The T-Box accepts 2 inputs (one from each party) and provides one output (seen by both parties). It ensures that none of the parties can determine the complete input of the other party.
Therefore by connecting 2 instances of a T-Box together (as in the case of a relay attack) the message from one end to the other (Alice and Bob in the image above) gets distorted twice as much as it would in the case of a direct connection. That’s the basic idea.
One important question is how does the T-Box operate on the inputs such that we can detect a relay attack? In the paper we describe two example implementations based on a bi-directional channel (which is used for example between a smart card and a terminal). In order to help the reader understand these examples better and determine the usefulness of our idea Mike Bond and I have created a python simulation. This simulation allows you to choose the type of T-Box implementation, a direct or relay connection, as well as other parameters including the length of the anti-relay data stream and detection threshold.
In these two implementations we have restricted ourselves to make the T-Box part of the communication channel. The advantage is that we don’t rely on any party providing the T-Box since it is created automatically by communicating over the physical channel. The disadvantage is that a more powerful attacker can sample the line at twice the speed and overcome our T-Box solution.
The relay attack can be used against many applications, including all smart card based payments. There are already several ideas, including distance bounding, for detecting relay attacks. However our idea brings a new approach to the existing methods, and we hope that in the future we can find a practical implementation of our solutions, or a good scenario to use a physical T-Box which should not be affected by a powerful attacker.
The Sony hack: passwords vs. financial details
Sometime last week, Sony discovered that up to 77 M accounts on its PlayStation Network were compromised. Sony’s network was down for a week before they finally disclosed details yesterday. Unusually, there haven’t yet been any credible claims of responsibility for the hack, so we can only go on Sony’s official statements. The breach included names and addresses, passwords, and answers to personal knowledge questions, and possibly payment details. The risks of leaking payment card numbers are well-known, including fraudulent payment transactions and identity theft. Sony has responded by offering to provide free credit checks for affected customers and notifying major credit ratings bureaus with a list of affected customers. This hasn’t been enough for many critics, including a US Senator.
Still, this is far more than Sony has done regarding the leaked passwords. The risks here are very real—hackers can attempt to re-use the compromised passwords (possibly after inverting hashes using brute-force) at many other websites, including financial ones. There are no disclosure laws here though, and Sony has done nothing, not even disclosing the key technical details of how passwords were stored. The implications are very different if the passwords were stored in cleartext, hashed in a constant manner, or properly hashed and salted. Sony customers ought to know what really happened. Instead, towards the bottom of Sony’s FAQ they trail off mid sentence when discussing the leaked passwords:
Additionally, if you use the same user name or password for your PlayStation Network or Qriocity service account for other [no further text]
As we explored last summer, this is a serious market failure. Sony’s security breach has potentially compromised passwords at hundreds of other sites where its users re-use the same password and email address as credentials. This is a significant externality, but Sony bears no legal responsibility, and it shows. The options are never great once a breach has occurred, but Sony should at a minimum have promptly provided full details about their password storage, gave clear instructions to users to change their password at other sites, and notified at least the email providers of each account holder to instruct a forced password reset. The legal framework surrounding password breaches must catch up to that for financial breaches.
Pico: no more passwords!
Passwords are no longer acceptable as a security mechanism. The arrogant security people ask users that passwords be memorable, unguessable, high entropy, all different and never written down. With the proliferation of the number of passwords and the ever-increasing brute-force capabilities of modern computers, passwords of adequate strength are too complicated for human memory, especially when one must remember dozens of them. The above demands cannot all be satisfied simultaneously. Users are right to be pissed off.
A number of proposals have attempted to find better alternatives for the case of web authentication, partly because the web is the foremost culprit in the proliferation of passwords and partly because its clean interfaces make technical solutions tractable.
For the poor user, however, a password is a password, and it’s still a pain in the neck regardless of where it comes from. Users aren’t fed up with web passwords but with passwords altogether. In “Pico: no more passwords, the position paper I’ll be presenting tomorrow morning at the Security Protocols Workshop, I propose a clean-slate design to get rid of passwords everywhere, not just online. A portable gadget called Pico transforms your credentials from “what you know” into “what you have”.
A few people have already provided interesting feedback on the pre-proceedings draft version of the paper. I look forward to an animated discussion of this controversial proposal tomorrow. Whenever I serve as help desk for my non-geek acquaintances and listen to what drives them crazy about computers I feel ashamed that, with passwords, we (the security people) impose on them such a contradictory and unsatisfiable set of requests. Maybe your gut reaction to Pico will be “it’ll never work”, but I believe we have a duty to come up with something more usable than passwords.
[UPDATE: the paper can also be downloaded from my own Cambridge web site, where the final version will appear in due course.]
Can we Fix Federated Authentication?
My paper Can We Fix the Security Economics of Federated Authentication? asks how we can deal with a world in which your mobile phone contains your credit cards, your driving license and even your car key. What happens when it gets stolen or infected?
Using one service to authenticate the users of another is an old dream but a terrible tar-pit. Recently it has become a game of pass-the-parcel: your newspaper authenticates you via your social networking site, which wants you to recover lost passwords by email, while your email provider wants to use your mobile phone and your phone company depends on your email account. The certification authorities on which online trust relies are open to coercion by governments – which would like us to use ID cards but are hopeless at making systems work. No-one even wants to answer the phone to help out a customer in distress. But as we move to a world of mobile wallets, in which your phone contains your credit cards and even your driving license, we’ll need a sound foundation that’s resilient to fraud and error, and usable by everyone. Where might this foundation be? I argue that there could be a quite surprising answer.
The paper describes some work I did on sabbatical at Google and will appear next week at the Security Protocols Workshop.