There is an old RFC that explains the problem in very simple terms. Security need to be transparent, or it fails. If the user need to see and use security in order to be secure, the user will eventually do something to render the security ineffective.
If you got passwords, users either pick easy ones or write them down next to the device that needs them. If you require physical "key" items, user leaves the key next to the computer that needs it.
When designing a security system you need to acknowledge this limitation, and design the system with it in mind. Running between "something you know" (passwords) to to "something you know and has" (Two-factor authentication like password and phone), and now back to only "something you have" (an USB key) won't solve the problem.
Because they're expected to be kept on a keychain which is commonly kept in one's pocket and which you'd rather not have filled up with chains and bulky cases?
That's just their small device (NEO). I have two of their normal sized one that I use for several sites already for 2-Factor. The YubiKeys are actually pretty robust and safe enough to keep on a keyring.
The key to this is to still require something that you remember like your username (and/or a password), they will get stolen and it is too risky for these tokens to be the only authentication factor.
As long as users are educated that these tokens should in all ways be considered a set of keys then security can only be improved with them.
In one place I know, the company combined the door key and the computer key into the same device to practically force people to take the key with them when they leave. They reasoned that if users can't leave the building without unplugging the key from the computer, then that would be that.
Of course, people still leave the key at the computer when they go and eat, bathroom, or when they leave the building as a group.
I have known a fair few people over the years who have had security tokens --to be able to login at work.--
For work purposes, i.e. you need it to do your job so it may be required at any point. TFA is saying people will leave it just by the PC they use most often, i.e. at home, which defeats the point.
I think the use of smart phones for 2-factor is the way to go, since it is not something else I need to carry around. Up until recently Barclays Bank (in the UK) had a fairly bulky card reader which I would insert my card, tap in my pin and it would generate a secondary password (I also have to chose letter X and Y from my password). They now have a smart phone app. Much simpler for me now.
Most of that can be taken care by a password storage, such which is included in most browsers already. However, currently browsers do lack a mechanism for creating a random password, so users tend to write during registration what ever gives them the easiest way to click continue.
> currently browsers do lack a mechanism for creating a random password
That can be easily solved by integrating a good password manager into the browser. There are plenty of plugins that automatically generate random passwords, insert them into appropriate form fields, and save them in a secure "vault" that is synched across devices. It shouldn't be too difficult for browser vendors to offer such functions by default, and gradually upgrade them to incorporate newer standards.
At least, it will be much easier than getting everyone to purchase a physical device, and it's even backwards compatible with existing sites that will probably stick around for another decade or two. I doubt that any solution to the "password problem" will be viable unless it were backwards compatible.
If the security is to authenticate a user, how do you do it without the user's participation?
You could go for biometrics. But that creates a new problem - unless you're deeply paranoid, you'll leave plenty of DNA, fingerprints and pictures of your irises, without thinking of them as security holes.
You could tie it to the device. But that's no good when you want to check your email on a friend's computer. And if your phone gets stolen with full access credentials... The device is not the same as the user. So I don't see how you can avoid some combination of 'something you know' and 'something you have'.
There is no silver bullets for now, so one need to design the system with the knowledge that any nontransparent security will be made insecure by the users.
What does that mean in practical terms? It depend. It can sometimes mean to move the question of validation to a third party. It can sometimes mean multilayer security, so once the first line of security features goes down, the damages done can easy be reverted. It can even be insurance against liability so the user's security mistakes do not damage the user. In some cases, one could have a complex revalidation system instead of an complex validation system, so that its first when a user switches a device (say a phone) that all the non-transparent security will show itself. It all depend on the exact details and what the exact threat model is and who the intended user is.
This is why in my mind, articles like this one are missing the point. They are trying to announce a silver bullet, when such thing does not yet exist even in theory.
That's not IT issuing you a new password, that's you changing it. The point is that biometrics are perfectly feasible as one of the two factors (instead of something you know) and can still be revoked.
I also don't leave my password on everything I touch.
Biometrics are a terrible idea. Password + token is much safer and infinitely revokable. And the server can even tell when an HOTP device has been cloned.
It's really only workable when authing to the device. Not over a network. I'd basically assume that anyone can forge your biometric info, so it's only applicable in scenarios where the forgery is hard to execute.
The difference probably stands in what it's meant to protect. If it gets stolen, it's not only a car, it's the key to your personal identity, along with maybe bank account, email, work secrets, etc. Losing that key would stress me much more than losing my car keys, even more if it just works in any computer with a USB port.
I don't disagree with what you wrote about going back the "SYH" being not that smart but...
It's not transparent when my 65-years old mom uses a physical device not connected to the computer, in which she enters her identity (Java SmartCard) card and perform a manual challenge/response to login and do her online banking.
It's a pain for her: it's SYK+SYH but it beats going to the bank all the time... So it's not transparent but it still works because she doesn't really have the choice.
Used one of these before (YubiKey) - they are an utter pain in the arse.
The contacts get dirty, they dont fit some USB ports properly, they die regularly, are absolutely no good if you don't have a USB port handy (my desktop for example doesn't have a USB hole in the front or on the keyboard or monitor, resulting in crawling around under my desk to authenticate) and to be honest quite fragile.
All it does is act as a USB HID keyboard and pump some text down when you press the button on it. It's basically about as secure as an RSA key but requires physical electrical contact with the machine.
FWIW, I've had one at work for a year now and I've had nearly none of the problems you've mentioned. It's fit into all USB ports I've tried, the contacts are still fine, it hasn't died, it doesn't seem fragile (or at least hasn't broken yet) and I haven't had to crawl anywhere to plug it in. The most annoying thing (apart from the general annoyance of a second authentication step) is that I can't use it via my phone; a screen on it would be handy for that.
I have had great success with yubikey for over a year. Their combo with LastPass is excellent. It even works on my iPhone/iPad with the USB adapter. I highly recommend you buy some and try them out. I keep a NEO in my rMBP and others on my wife and my keychains for our multiple computers. LastPass allows you to link several yubikeys to one account for a great 2 factor auth secure password store.
The contacts get dirty, they dont fit some USB ports properly, they die regularly, are absolutely no good if you don't have a USB port handy (my desktop for example doesn't have a USB hole in the front or on the keyboard or monitor, resulting in crawling around under my desk to authenticate) and to be honest quite fragile.
I've got some hard to access USB ports, too. I solved that problem by buying some USB extension cables (male on one end, female on the other). They are very inexpensive. Give them a try, you won't be disappointed. No more uncomfortable hunting for USB ports under the desk!
I really like the idea of the Yubikeys, but I had one fail on me after I touched it and experienced a static shock.
Another problem is they don't work if the OS is configured to an alternate keyboard layout. The default hex encoding assumed QWERTY, but I use Dvorak. Perhaps this has been remedied in newer models.
"In a 21 March 2011 email to customers, RSA essentially admitted that the information stolen from their internal network could allow an attacker to compromise a SecurID-protected system without having physical possession of the token."
This is actually why two factor authentication is great. In this instance, users were still protected (at the least) by their PIN.
This is somewhat equivalent to losing your ssh private key. Yes, it's bad, but your passphrase should ("should" -- at least it's not an immediate breach like losing a password or clear text private key) buy you enough time to revoke and replace the key.
Exactly. Until we can come up with a better system the rule of thumb is:
1) Know something
2) Have something
Its somewhat easy for a potential cracker to gain access to either one of the two, but extremely difficult to have both.
Hell, when I used SecurID at one of my first jobs you had a PIN to go with the token number, almost like a salt to your password. Even if they had the key they wouldn't be able to access my accounts.
Yubikey's are different in that there isn't (well, doesn't have to be) a centralized location where management of the keys is handled. Yubico offer a solution where you can authenticate/issue/revoke keys from within your own infrastructure[1]. So long as you keep that secure (say with HSM) you should be OK.
According to Fedora wiki they're used to create OTPs (one time passwords), but still... I don't like the idea of a physical token that can be stolen and used without verifying the user (meaning that you still need user/password or any other auth mechanisms to complement the Yubikey).
Yeah you will still need username/pass for google I'm sure. Although they mentioned something about a ring? NFC maybe?
If you run your own server, though, you can set up challenge-response on the Yubikey which might make things easier by allowing maybe a PIN instead of a password.
Hopefully one day soon we will be able to authenticate with behavior; maybe a combination of gate/speech cadence/facial structure. Or maybe like a Rorschach test instead of username/password field :)
Google already has the two-factor authentication with Google Authenticator for iPhone and Android. I use it for my Google account and (this is the awesome part) other websites that use their API to add their auth keys to the Google Authenticator app on my phone.
There is a problem with Google's two factor solution. If you need to use things outside the browser (eg checking email via imap, chat via xmpp) then you need to generate secondary passwords. That is fine. What isn't is that those passwords are not scope restricted - ie if you generate a password for imap access then it can be used for anything else (eg chat).
What happens when you want to leave Google services?
You will be locked in. I remember the days when everyone had hotmail. At some point you will want to leave gmail or google apps. Genius move on their part though.
I understand your point, but I do think Google may be a bad choice of examples. If I'm not mistaken (correct me if I am), they have or are implementing some data liberation functionality to download your data from their systems.
My work blocks Google Account access so I can't quite verify this for you, but I believe it's there. I'm not sure how far it spreads across their product offerings though at this point.
what is so frustrating is that Google don't actually seem to support OpenID or OAuth the other way round. Why can't I log into Google Docs with a company OpenID account? Why can't Google Google Docs pull company data using OAuth? They support it as long as they are the provider. But in a commercial setting the business itself is the legally culpable provider of authentication and authorization and would be absolutely crazy to put it in the cloud in the way that Google are begging them to do.
I'm not sure I understand how this stops a person from leaving Google's services in favor of another? I admit I'm a little ignorant of OAuth, so any light you can shed on this would be great..
Just as one note on that, it isn't an API but rather are existing standards (TOTP and HOTP). Google Authenticator the application uses a very simple text pattern for the QR-code that anyone can emulate. It is good stuff.
I think if a mammoth like Google pushes forward strongly enough, it might achieve some results. And it probably takes all its mass to push this particular piece - the almighty and alstupid password, away.
I'll bet that human beings in 20 years, looking back at our times, will point fingers and say "How we have been so silly! Passwords are the worst authentication mechanism, and so obviously flawed! How come did we not use x or y?"
I see another thing that they will point fingers at: the human driven cars: this is so frightening, when you think about it. You have this thousands kilogs wheeled machine, driven by almost anyone including drunkyards, grannies, people who just married and people who just divorced, and a sec of inattention and you send families to the grave.
Actually, I think passwords are a brilliant authentication mechanism that will continue to have a place in computer security for many years to come. When used correctly, a password implies the presence of the correct brain. Not a device that can be lost or stolen, not even a fingerprint that can be lifted. Authentication based on information stored in your neural network might not be suitable for everyone, but at least among competent professionals, I don't see mobile phones or USB dongles replacing the passphrase on my PGP key anytime soon.
I agree with your statement with one minor change: a password (or better, passphrase) is a brilliant authentication...
Passwords (plural) are just about the worst authentication mechanism. While brains are good at remembering one such token, needing to remember many for many different sites (and which ones go to which) is simply untenable. Additionally, the ability to easily compromise them through phishing makes them awful.
I wonder if there'd be a way to cleverly move the hashing (that all servers should be doing) to the client side such that all of the above problems could be solved. It would confound password changes, however...
There is. Or, a variety of ways, really. Two major ones:
Option 1: your passphrase as a salt + the domain name + bcrypt = password. Lots of detailed schemes exist for this, including ones you can do on a piece of paper with a little math so you don't have to trust your computer. Inventing them seems to be a hobby for crypto people, or something - I've seen many dozens.
Option 2: you use random passwords, and store them behind your passphrase somewhere. Password managers.
At no point does your single, secure password enter anyone else's hands, so you don't need to trust them to hash it. If one is compromised, none of the others are.
Yup, exactly option 1. But browsers need to support this intrinsically and universally. By salting with the domain name, you remove phishing.
Password managers (especially in terms of built-in browser support) are generally a one-machine solution. Yes, there are ways to sync them to mobile devices and the cloud and such, but there's a lot to be desired in terms of portability. I currently use 1password, and it works great for me. I set my mother up on it, too, but it's only a 90% solution for her as she's not quite technically proficient enough to ensure it works all the time.
My question was more if there'd be a smart way you could add one more level of indirection such that: 1) individually compromised passwords could be changed and 2) the master password could be changed without affecting every single site.
Ideally neither situation would be necessary, but servers will be compromised.
I'm personally not a fan of 1, and I don't know that it can ever work to complete satisfaction. Two reasons:
1) domain names change sometimes. especially with the current trend of weird ending domains, and "www.getx.com" which later becomes 'x.com' when they finally pay the squatters. Or a rebranding, or subdomains, etc. How do you handle changes, without recording them? Proactively you can change your password when such a thing occurs, but that's not a reliable assumption.
2) versioning. If you have to change a password every X time periods, how do you track which version you're on? without a database? you could salt it with the time the last password was created, but what about time zones? different calendar systems (did I set that password in china, or jerusalem, or canada...?)?
All of which leaves you with a database of some kind in some (fairly likely to occur) situations, which means you essentially have a password manager. As you point out, a 90% solution simply isn't good enough.
> Password managers (especially in terms of built-in browser support) are generally a one-machine solution. Yes, there are ways to sync them to mobile devices and the cloud and such, but there's a lot to be desired in terms of portability.
I use LastPass, and it's about as cross-platform as any app can be. You just need to reconcile yourself with the fact that your passwords will be uploaded (encrypted, of course) to a third-party service. It's also a piece of cake to change individual passwords or the master password without affecting anything else. Most importantly, you get the same anti-phishing benefit as option 1 because LastPass won't offer to auto-fill your password if you're on the wrong domain. You don't get this benefit if your password manager is outside your browser.
Use a password manager. Random, unique passwords for every site, and one long master passphrase that is stretched by the password manager.
With random, unique passwords, resource-intensive server-side hashing provides no benefit. We are doing that because people re-use their passwords everywhere.
Right, but I was not talking about passphrases giving root access to critical machines or documents. I was talking about passwords for Twitter or HN accounts, or those used heavily in entreprises. I have a friend head of something in a big corp, she says she has at 6 passwords with 6 different policies and has to use them everyday, sometime just to sign the invoice for a new ink cartridge.
If you can update it, trivially, presumably without using the heuristics themselves, someone can update it for you. Now you have a new problem (securing the method for updating the heuristics.)
Although a counterpoint to this would be using more unique points of reference like the iris, fingerprints, etc, things not likely to change.
So the current heuristics are no longer valid (e.g. you were in a car wreck so you're hunched from back pain and have a black eye), and you're going to use the current heuristics as a gate to updating the heuristics?
Imagine if the "forgot password" link on a website gave you a form that said "enter your current password and then you can set a new password". This is the scenario you're describing.
Think of it like Paxos. As long as a majority of unique data points agree, allow access. That way if your back is out which results in your posture being unrecognized, the other factors can still form a quorum and grant you access. There could be 20 such factors weighted by "difficulty to forge", so that a fingerprint counts 15x as much as posture for example. Then if you successfully authenticate with, say, 80% on all data points then the system can allow you to train a new factor.
> They see a future where you authenticate one device — your smartphone or something like a YubiKey — and then use that almost like a car key, to fire up your web mail and online accounts.
> That means that if someone steals your card or your smart-ring, you’d better report it stolen pretty quickly.
I won't be surprised if thieves devised a method to extract online credentials from a stolen device in a matter of minutes, if not seconds. Since any password you have on your mobile device is unlikely to be strong (the article specifically mentions that you won't need a strong password on your device), it will also be a piece of cake to brute-force it. Meanwhile, you're without a phone, desperately looking for a payphone or Internet cafe where you can contact Google. Too slow.
At Clef(clef.io) we're storing keys on your smartphone and they're protected by a PIN wall. We used PIN-based encryption to keep a rooted device from being vulnerable to attackers. Generating the keys from the PINs take long enough to make a brute force attack time consuming. Since users can deactivate their devices remotely if they're stolen (so the public side of the key pair is deleted and the private side is worthless), even in cases of device theft, their identity is protected.
They don't currently provide ways to force password age rules for corporate google users. So corporate clients that want to use google apps are currently forced to use an IdP that does this for them.
They have the tools to allow for it, we even give corporate customers a way to use Google Apps accounts and force 2-Factor auth and password aging without things like Active Directory.
Also not providing the ability to change session information is, well, a little off putting for some. It's not that it's a war on the password it's just that they don't want their services to be something you actually have to log into (chromebook experience).
Those of you how own Dell or HP Computers - you may notice that most of the professional grade laptops have smart card readers built in. My guess is this is due to DoD purchasing requirements. Of course, the MacBook doesn't have a smart card reader and thus you start to look for solutions like the YubiKey.
The military didn't solve the problem. They solved an easy variation. The problem is not just "How do I make it easy and secure to access the systems I control?" but "How do I make it easy and secure to access all systems?" The military implemented 2-factor auth and unified their systems to support it. This is very nice, but doesn't solve the broader problem. Military employees are still struggling with the same "million not-very-secure passwords I can't remember" problems as civilians, because they military does not control all or even most of the systems they interact with.
This seems like an interesting solution to me. Obviously we have gotten to a point where our computing power has rendered the kind of passwords that most people can easily remember and use fairly trivial for many password cracking methods, and so there is a clear need to develop a convenient method of using more complex methods of authentication.
The idea of using a smartphone as a central area for things such as identification and payment(Google Wallet) has been something i've been interested in for a while, and something I think could be amazing if we manage to work out a few kinks that are in the way of making it a viable option.
For this to become a reality i think there are 3 main things that would need to happen:
1) Battery life on smartphones would have to become a lot better, I don't want to have to worry about if I'm going to have enough battery at the end of the day to pay for dinner, get into my car, etc.
2)The ability to remotely clear data on a device that may have been stolen need to become a standard.
3)There need to be some sort of authentication between the user and the device in order to approve the use of stored authentication.
In 1998 Bill Gates (American Banker article, and elsewhere) said that the future of ecommerce was based on replacing passwords with smart cards....hmmm how did that work out :)
Remember AMEX Blue? they stopped sending out card readers almost immediately, but continued sending the smart cards out and running TV ads with all sorts of Terminator like special effects to promote how secure its smart cards were.
It was a huge marketing success, but the smart card part was never used.
Security is an illusion.
Actual conversation....
Naive dev: Hey Big Bank, we invented this revolutionary perfect authentication technology! no more hacks!
Big bank: why would we want to redirect the hackers to a new attack that we don't understand, cannot model, cannot assign a stable cost to, and would almost certainly expose even worse flaws in other parts of our systems? as long as fraud is between X and Y %, we WANT the attacks to use the current vector.
Naive dev: ooooooooooooooohhhhh (world view changes)
Here in several european countries people are doing just that:
- using a Java SmartCard (your identity card) + a card reader (not hooked to the computer) + a PIN to connect to your online bank but ALSO to challenge/response any VISA/credit card transaction.
If I'm not mistaken there are about 200 millions citizen in Brazil who have a Java SmartCard as their identity card (as a medical care card I'm sure, identity I don't know for sure).
I think it's a bit early to decide that it failed and that it's an illusion. There are probably hundreds of millions of people who are carrying daily a Java SmartCard and using it to perform kinda safer online transactions.
MITM attacks over unsuspecting users are still possible using "mocking birds", but it's becoming harder and harder to game the system.
An identity card is not a commerce solution -- there is no cost/benefit analysis for governments, they just decide which vendors should get lots of money (I know, I was one of them! Thanks governments!) We did this in the US and now there are no fake passports here in the US, we win! Ooops...
http://www.schneier.com/blog/archives/2006/08/hackers_clone_...
I think you'll see that it concludes much the same thing as I mentioned the banks (here in the US anyway) conclude: the costs are not worth the theoretical "kinda safer" gains in security.
Security is a nuanced, no-one-solution-fits-all, dynamic, evolving systems engineering problem. The adversaries are smart, but more importantly have common sense (unlike governments and consumers) - they will exploit weaknesses in the weakest link. Replace passwords with smart cards, no problem - they will go after the next link. The (US and EU) banks know this -- they all employ layered fraud and security measures --- despite consumers who may have unquestioning faith in the perfect security of smart cards.
And when you come back in 5 years and payment cards are still NOT being used in the mainstream (US anyway where cost vs. benefit is important), please have the courtesy to up vote.
Why can't we just all get along, and say, for example - instead - that "rsa_key.pub" is all we need, and if we ever get a logon prompt, look for that file on USB media instead ..
I mean, that would work, wouldn't it? I suppose for it to work, though, we'd have to have an actual .. you know .. OS Company .. again.
The Yubikey would only work if there was an absolute guarantee that a hacked kernel/drivers would not be able to access the memory.
The way I can see it working is if there is a private key on the device, inaccessible to the host hardware, and the crypto stuff is done on the device - so the Yubikey was effectively the client. Auth service sends challenge to the browser which sends it to the driver which asks the yubikey wtf, the yubikey responds to the challenge, and the response is sent to the browser and back to the host.
But this would all fall down if there was even the slightest chink and your host hardware could be modified to access/save the keys on all of the Yubikeys when they are plugged in.
The biggest problem I see with all of these proposed ideas is that people often need to be able to share access to accounts with others. Yes, sharing a password is the wrong solution to that, but usually it's the only solution, and it will be until there's an accepted standard procedure for providing limited access to your account via somebody else's key.
So they’ve developed a (as yet unnamed) protocol for device-based authentication that they say is independent of Google, requires no special software to work — aside from a web browser that supports the login standard — and which prevents web sites from using this technology to track users.
On top of my head I can think of it being stolen. Unless you need a password on top it (ironic, no?)
and then ..." Under threat of a boycott, Intel Corp. backed down slightly yesterday from a controversial plan to add a security feature to its computer chips, but privacy advocates said the change doesn't go far enough to ease their concerns.
Privacy groups fear that the new feature, sort of a Social Security number hard-wired into computers, would be used to monitor Internet users' activities online, allowing companies to collect marketing data on them. "
http://news.cnet.com/8301-27080_3-20126770-245/intel-chips-l...
Personally I'll stick to passwords, little by little they will add code and "features" to that usb stick. Call me paranoid but Google has more than enough info on me and what I search /ed for.
Before everyone just on my throat saying I'm a naysayer I'll state that I love the idea.
However why oh why on earth is the YubiKey challenge/response optional?
Why can that thing work in a mode where it simply "dumps text"?
It's terrible that it's optional because it means that I cannot be sure in which mode that thing is operating right!?
But I love the idea: we need more physical tokens doing challenge/response and less "let me store this in my phone's 'master app of all the passwords'" snake oils.
If you got passwords, users either pick easy ones or write them down next to the device that needs them. If you require physical "key" items, user leaves the key next to the computer that needs it.
When designing a security system you need to acknowledge this limitation, and design the system with it in mind. Running between "something you know" (passwords) to to "something you know and has" (Two-factor authentication like password and phone), and now back to only "something you have" (an USB key) won't solve the problem.