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’t download your PDF…
http://spw.stca.herts.ac.uk/3.pdf
Gets stuck at 28% …
thanks
URL works fine for me. Try right click and save as, then read the PDF from your hard drive.
Pardon my bluntness, but wouldn’t we be better off promoting Smart Cards?
They exist, have good support in all the major browsers, and provide the level of device security needed. I use one to access things like phpMyAdmin on my web server.
I can think of 3 issues with SCs currently;
– they aren’t easy to obtain by Joe Smith (either buy in bulk, pay through the nose, or buy from random sellers on eBay)
– some vendors don’t release drivers to the public
– a global, public, low-cost CA would need to be created, with a key revocation & reissue process for when cards get lost (for people in countries that aren’t issued national ID cards with a SC built in, or issued one by their employer)
… but those could all be addressed by a single organisation (or consortium, which could provide local support) if people were serious enough about replacing passwords.
Either way, promoting smart cards would be legions easier than creating new hardware.
Interesting ideas, would like to ask you if you would be interested in speaking at Passwords^11 in Bergen (Norway, June 7-8?
CFP is available at my blog: securitynirvana.blogspot.com
🙂
One problem I’ve been giving some thought to lately is how essential credentials are passed along in the event of death or if power of attorney is invoked, which might mean the biometric isn’t available. Requiring a biometric is problematic in any case should the user suffer an injury, even a temporary one, that prevents the biometric from working. Should there be a way to reset these outside credentials or perform recovery operations when one or more pieces is unavailable? The natural concern is that this pretty much always involves a lower security state which is then an avenue of attack.
@ handslive,
“One problem I’ve been giving some thought to lately is how essentia credentials are passed along in the event of death or if power of attorney i invoked, which might mean the biometric isn’t available.”
First off biometric ID is a very bad idea just about every way you look at it, starting from the simple case of unreliability moving upwards.
However there is a major issue with it that people are just not talking about and it applies to National ID cards and other “centralised ID / authorization” systems.
And. it is “roles” the one advantage multiple paswwords and usernames has is that they are all effectivly independnet of each other. If a user choses to use a password manager on a single device that should be their choice not that of others. We appear to think that “Single Sign On” is a wonderful ideal but for whom and why?
As a basic fundemental right we should not be restricted to a single ID that is not how we function as humans and things like biometrics are a very bad idea fundementaly because the try to impose on people something that is not natural to them (even if the don’t realise).
Just about everybody conforms to multiple social norms such as,
1, Father / Mother
2, Daughter / Son
3, Brother / Sister
4, Husband / Wife
As we also have multiple other roles such as employee / employer, member of a club or association etc etc. The list can be almost endless.
And importantly it is upto us as individuals to decide who should and who should not be privy to the various facets or roles of our lives. It is an essential part of our ability to maintain space and distance from others and thus maintain some semblance of privacy and thus sanity.
Anything that tries to change the normal multifaceted individual into a single ID is doomed to failure in the long run and it is a point most system designers do not appear to understand.
Certainly most applications like web browsers do not support it currently and in many respects it is responsable for many ot the security problems we see.
@ Frank,
What sort of PDF file is it because it refuses to open with my ordinary browser.
@Clive
I think you really hit the nail on the head there. We are different people in different environments. This is normal – not in any way subversive – and essential for us to manage our lives.
Someone (possibly Ross Anderson?) published an ingenious idea for combining biometrics with a token a little while ago.
The idea was that exactly one biometric — iris prints — had high stability, good EER, low FTR, high data density, high read rates, and low cost equipment; but that, like all other biometrics, it was still easy to steal and impossible to revoke.
So an iris scan (and possibly also a PIN) would be passed in to the token and mungified in a very clever cryptographic way to produce diversified keys for various services. The munigification takes into account the noise in the biometric scan whilst still using a large amount of entropy from it. Obviously these keys are easily revoked, and as they were to be used in various authentication protocols, on-line interception should be useless.
The mungification process was designed in such a way that an opponent who stole either the iris scan OR the token (and managed to extract secrets from the token) learned nothing at all.
It was a pretty neat process. Obviously not completely foolproof, but leagues better than anything else widely available to the common man. I would only use it for high security applications if the third factor (PIN) was also pretty strong, but even without a PIN, I think it is the only affordable biometric proposal that I have seen which is suitable for regular public use for stuff more serious than a gym locker.
Oh, and Frank,
I meant to say that I also had a lot of trouble downloading your PDF. On the third attempt it has finally got past the 50% mark. It currently thinks it is up to 71%, but has taken well over 5 minutes to get there. I think it may time out again.
It’s the first time when I met a such approach of the passwords issues, however I consider this brilliant. I’m thinking at banker trojans: how Pico deal with them ? Because for these type of trojans, does not matter the length or the complexity of a password. These trojans are able to hook API functions and to inject themselves in the browser process, altering entirely the browser behaviour.
“With … the ever-increasing brute-force capabilities of modern computers, passwords of adequate strength are too complicated for human memory”
I do not see how the increasing speed of computers has any detrimental effect. The CPU time for the password hashing algorithm can just be kept constant as the computers become more powerful. It should be an approximate number of CPU milliseconds rather than a fixed number of rounds of a hash. So the passwords do not need to become more difficult as the machines become more powerful.
@ Axelle, Clive, Roger and anyone else having problems dowloading the paper:
I have added another link (on my web space here at the University of Cambridge rather than on the workshop’s site) from which I hope you might have better luck.
@Jed:
Smart cards might be part of a possible solution but it’s not clear how you envisage they should work. From your mention of “a global, public, low-cost CA” and “national ID cards with a [smart card] built in”, it seems that you intend the smart card to serve as your global digital identity. From a privacy viewpoint I would not be happy with such an architecture, which would make me linkable across all verifiers.
@Per:
Interested, sure, thank you.
@ Handslive:
I find your comment on “how to pass on my credentials in case of death” interesting and insightful. I’ll have to tackle it in the full paper, with credit to you for mentioning it.
I don’t think there should be a way of gaining access to the credentials of a locked Pico without all the pieces—that would be like key escrow and it would, as you say, reduce the security.
My solution is that, if the owner of the Pico cared about this issue, as they should, they would (optionally) create a “digital will”, bequeathing a usable backup of the Pico to a nominated beneficiary. This backup would have to be kept very secure (with secret sharing, and involving the notary to whom the will is entrusted for safekeeping) until the time of opening the will, because it would allow a full takeover of the user’s digital identities.
Usual problems (just like in the real world) if person dies without preparing a will. I admit that as a privacy-oriented person I err on the side of confidentiality rather than availability here, but that some users might have other priorities that ought to be taken into account too.
@ Clive:
I fully agree with you that centralized authentication (in the style of national ID cards) is a bad idea and a privacy threat, and that a good user authentication method should not allow linkability between authentications of the same user to different verifiers. But it’s clear that you hadn’t read the paper when you wrote that comment (indeed in the next message you say you could not open it—please try the other link I added).
When you do read it, you’ll see that Pico was designed for privacy. Not only it’s a system in which you can’t be linked across different verifiers: it’s a system in which, even if you have several accounts with the SAME verifier, that verifier still can’t link them and figure out that they all belong to you (unless you give the game away in other ways, e.g. by connecting through the same network address or by revealing it at the application layer). On top of that, your Pico doesn’t even disclose your identity to the app until AFTER the app has authenticated itself to your Pico.
I don’t use a biometric as a global ID. I use it to unlock the local device. Big difference. I agree that the former would be misguided.
@ Roger:
That was Ross’s student Feng Hao, now a lecturer in Newcastle. I refer to his work (in shorthand) at the bottom of page 13.
@ John_:
If you type the password, it can be captured by a keylogger.
The most treacherous type of keylogger is the hardware dongle hidden in your keyboard or keyboard cable (or USB hub, or…), because it is undetectable by software.
The software keylogger can in theory be detected by software (at least if the detection software has a chance to run before the keylogger) but it is more easily deployed by the attacker because physical access to the victim’s computer is not required.
When using the full-fledged Pico, you are protected from either type of keylogger. When using the backwards-compatible less secure version that remembers passwords and types them for you (section 5.2), you would be protected against a hardware keylogger but would potentially be vulnerable to a software keylogger, as noted in the paper itself. But that’s an inherent failure of using passwords, not of Pico, so it’s part of the price of backwards compatibility.
@ Richard:
A valid point. But it assumes that the only relevant advances in the “ever-increasing brute-force capabilities of modern computers” are those that speed up the CPU. Your adversaries might instead be using a massively parallel machine like Deep Crack.
Moreover, in practice, I am not aware of many password verifiers that fine-tune the number of hash rounds whenever they upgrade the servers in their machine room—most will just use a library function as is. Indeed, according to the evidence collected by Bonneau and Preibusch, we’re lucky when web sites hash your password at all, rather than storing it in plaintext.
“Your adversaries might instead be using a massively parallel machine like Deep Crack.”
Good point, but we could counter this problem too at an algorithmic level by making our hash algorithm exercise more of the hardware. For example presumably the Deep Crack chips had very little randon access memory and disk space. We could make these things a necessary part of the algorithm. Our password hash algorithm could automatically probe and adapt its resource requirements to fill as many as possible of the capabilities of the hardware it is running on.
Interesting paper.
@Richard:
Thank you.
You certainly can make it exercise more of the hardware, but then it will cost more to everyone—attacker AND defender.
Even if you did write an “adaptive” password hash algorithm, it could only adapt to the verifier’s hardware, not the attacker’s. And it would not be allowed to adapt again if the verifier’s hardware changed, otherwise its own verifications would fail. For any given input, the algorithm must have a well defined output in order to match the stored result, so you can’t force it to do more work gratuitously just because it’s running on a bigger computer.
@Frank
I am assuming the attacker is building a machine with a different architecture, such as Deep Crack, where I guess each processing element only has the capabilities needed to perform a specific operation. I could not immediately find the details of their processing elements, but suppose for example they each have 1MB of random access memory. If we made our hash algorithm require 51MB of memory, and this would be easy to do, then they would have to equip their machine with 50 X NumberOfProcessingElements MB of extra RAM. But since most web servers already have upwards of 1GB of RAM allocating 50MB temporarily to our hash algorithm has very little cost and no extra hardware. What I was thinking was that taking this line of reasoning further we can effectively force each of their processing elements to have similiar capabilities to our server which would make it unlikely that a custom architecture machine would be more cost-effective to them than ‘owning’ very large numbers of server-architecture machines. Maybe it would be tricky to exercise every aspect of the hardware, but we can do better than just CPU milliseconds.
The hash can adapt to more powerful hardware by adding an extra ‘layer’ on top of the existing one. It will need a version number on the front to identify how many layers it uses and when the database is moved to more powerful hardware the existing hashes can be upgraded – without any need for the users to log in – by adding a layer. For example
v1 = MD5(password)
v2 = SHA256(v1, salt)
v3 = 1000 * SHA512(v2)
etc
I am assuming the first layer is not horribly broken somehow. We could imagine more elaborate nesting to exercise different hardware. We are constrained to always upgrading to more powerful hardware, never the reverse.
Interesting title of the paper: in Chile it will not pass unnoticed! 😉
best,
claudio
Hi Frank, I really enjoyed this talk and wanted to pass on the following comment.
While watching your presentation I sometimes felt I was in the Rump Session but other times quite inspired. Your presentation of an incomplete schema, but also with no IP ties is brilliant. Hopefully the scheme gets fully completed and debugged via this crowd sourcing.
Usually security designs are put up there fully thunked out or not put up at all.
I’d love to see a matrix of the various other schemes you mentioned evaluated against your list of criteria. Have you considered also evaluating Passpet (http://passpet.org/) against the same set of criteria?
Position paper is all very nice, but smartcards are obviously related work. You can buy SSO software today that comes with USB tokens that include a smartcard and some 1G bulk storage. It seamlessly works for Windows Login, S/MIME,file encryption, VPN client and usually also provides a simple password manager with auto-fill for your browser.
So if you take security research seriously, you should say what makes your scheme better than that and why it cannot be implemented based on smartcards. From what I can see, what you describe is equivalent to “everyone should use a personal smartcard-based credential management and all authentication procedures should switch to use smartcards/pk-auth.”