Slashdot Mirror
U2F Security Keys May Be the World's Best Hope Against Account Takeovers (arstechnica.com)
earlytime writes: Large scale account hacks such as the billion user Yahoo breach and targeted phishing hacks of gmail accounts during the U.S. election have made 2016 an infamous year for web security. Along comes U2F/web-security keys to address these issues at a critical time. Ars Technica reports that U2F keys "may be the world's best hope against account takeovers": "The Security Keys are based on Universal Second Factor, an open standard that's easy for end users to use and straightforward for engineers to stitch into hardware and websites. When plugged into a standard USB port, the keys provide a 'cryptographic assertion' that's just about impossible for attackers to guess or phish. Accounts can require that cryptographic key in addition to a normal user password when users log in. Google, Dropbox, GitHub, and other sites have already implemented the standard into their platforms. After more than two years of public implementation and internal study, Google security architects have declared Security Keys their preferred form of two-factor authentication. The architects based their assessment on the ease of using and deploying keys, the security it provided against phishing and other types of password attacks, and the lack of privacy trade-offs that accompany some other forms of two-factor authentication."
The researchers wrote in a recently published report: "We have shipped support for Security Keys in the Chrome browser, have deployed it within Google's internal sign-in system, and have enabled Security Keys as an available second factor in Google's Web services. In this work, we demonstrate that Security Keys lead to both an increased level of security and user satisfaction as well as cheaper support cost."
The researchers wrote in a recently published report: "We have shipped support for Security Keys in the Chrome browser, have deployed it within Google's internal sign-in system, and have enabled Security Keys as an available second factor in Google's Web services. In this work, we demonstrate that Security Keys lead to both an increased level of security and user satisfaction as well as cheaper support cost."
The only concern I have is that in some environments, the USB ports are disabled for security reasons. Also, how long do we have to wait before some exploit is embedded in those USB stick? ;-)
Everything I write is lies, read between the lines.
"the keys provide a 'cryptographic assertion' that's just about impossible for attackers to guess or phish."
Do you know how many times we've heard this kind of claim in the past?
I'd love for it to be true this time but I'm not going to hold my breath.
Just cruising through this digital world at 33 1/3 rpm...
I use the native 2FA feature for Gmail that leverages an app on any smartphone and it works great. No USB port required. https://www.google.com/landing...
"Persistence is annoying success." - ghee22 11:28:1999 - 10:53:PM
We have good 2FA now and hardly anybody uses it.
Google Authenticator is free, SMS 2FA isn't wire-secure, but it prevents almost all account takeovers, and "nobody" uses them because they're not mandatory.
But now we'll have a hardware dongle that will either fit in a computer or a phone, but not both (probably) and nobody will use those too? We got stronger crypto but we didn't need stronger crypto; what problem is this solving?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
does it run on Linux??
"I don't know, therefore Aliens" Wafflebox1
The bolder the claim, the more skeptical I get.
Water is wet and rocks are hard.
If you still don't realize that secure 2FA is better than a password alone, I don't think a published article about the topic is going to change your mind. Unfortunately.
Of course portable hardware based 2FA is more secure than nearly any alternative.
The problem is that this isn't "true" two factor authentication. This is just an (extra) client-side key embedded in a USB stick, you can do the same (much more universally) with SSL keys which is better than a password but in no way is it either foolproof nor 2 factor authentication, both of the items are passwords, you're just saving a really complicated password in a keychain.
A good TFA requires something two out of something you have, something you know and something you are. Something you have should be separated from and not influenced by the machine you're using to authenticate with.
Custom electronics and digital signage for your business: www.evcircuits.com
Everything is hackable.
Apple is pushing two-factor authentication right now, with an implementation that sends a numeric code to any of its devices that are registered to you other than the one on which you are authenticating. If you have two iPhones, an iPad and an Apple computer and change your Apple ID main password, two-factor auth takes you through several rounds of authenticating the change on each possible permuted pair of all of your devices. You will spend most of a day just entering two-factor authentication codes on one device after another.
Because of the messiness involved with changing an Apple ID password you make a point of never intentionally changing it - except that every third or so operating system update adds more rococo clauses to the ever-stiffening list of requirements for this password, requiring you to change it. Let's see now, three or more capitals, at least four numbers, an emoji, and two Unicode kanji....
Cupertino might consider replacing the numeric two-factor with a Bluetooth, rather than a plug-in, implementation of this hardware dongle. Place your dongle close enough to all of your devices, and it merrily plays its part in all of the authentications.
But, once compromised all your accounts belong to us.
A good 2FA is a simple SMS code sent after initial log-in. Almost everyone has a cell phone with free text messaging, and SMS is more secure, even if you are signing on from the phone's web browser. It requires no extra hardware than you should already have.
"Hi, I'm from your company's tech support team. I'm here to test your 2FA key to see if it needs to be replaced by this fake-o virus carrying USB key I'm carrying, mind if I check things out? I'll be needing that key...."
hope it works
That's still something you know. You know the code. You aren't proving that you have the phone number - SMS is incredibly insecure, numbers can be rerouted to other devices, someone else could have your phone, etc.
People will just leave it plugged into their laptops/desktops, so how is it different than any other client-side key stored on the drive. Am I missing something?
A challenge against a private key on an external hardware device doesn't count as a second factor to you? (Something you have)
First factor being something you know (a password).
Are you thinking it just spits out the same answer everytime?
This is better than the typical deployment of ssl keys since you can copy those off disk.
It's more like using a smart card but this is also better in that it's a different keypair per site without needing a central authority that could track you by noting where it processes requests from.
https://www.yubico.com/about/background/fido/
"A U2F device generates a new pair of keys for every service, the public key is only stored on the specific service it connects to. With this approach no secrets are shared among service providers, and even low-cost U2F devices can support any number of services."
and not influenced by the machine you're using to authenticate with.
The machine can't alter the response and have a valid signature when the response is signed by the private key on the external hardware dongle.
Maybe I just don't understand.
What sort of man in the middle attacks do you envision the machine you're using will be able to perform between the dongle?
Why is this not enough?
The browser also has access to RAM, the display, the hard drive, the CPU - just not directly.
Why would it need direct USB access for this? The device (or better, the OS) would provide a driver, and the browser only communicates with that.
We'll see how this one turns out once it's had some proper review.
Just developing something in public and doing RFCs won't attract as much efforts as possibly knocking down something published, a feather in the cap for defeating Google's propeller beanies. Whereas the first is just, "was a helper", which matters for just about zilch in any CV.
"something you are" if you can remove it with a knife, it isn't something you are. Also, once your biometric fingerprint (of any sort) is compromised, it's difficult to get the CA to issue you a new one.
We run general purpose computers. Can't we trust our own operating systems enough to think they might store a couple bits of secretish data? If not, what good is any encryption since the attackers get every session key anyway? (not to mention the keylogger with the raw password and the memory debugger that sees every block encrypted and decrypted)
The only thing a dongle provides is certainty that another computer can't impersonate a fully compromised device without the dongle. Of course, dongle-failure could very well lock you out of your own services. (and with a back-door in place, session hijacking is very possible)
Many sites, like gmail for example, require "registering" each new device via phone IM or pre-shared key. This happens after password success. Secret keys are then created and stored as securely as the device is maintained. Only if the device is deeply compromised will they be stolen.
If we create a landscape where 90% of computers AREN'T compromised thoroughly this really isn't that horrible. Throw in a bit of geo-location and email warnings about every interesting event (password change, new device registration, stale device login, Computer moved to Ukraine) and really things aren't all that bleak especially for services used every day or even once a week.
Then of course, there's cracking down on IP's and ISP's generating compromising packets, but that's a whole other subject.
See: 18 U.S. Code 2701 - Unlawful access to stored communications
After more than two years of public implementation and internal study, Google security architects have declared Security Keys their preferred form of two-factor authentication.
OK Google, then offer to ship these dongles out to your users at no cost. I'm not going to buy yet another little thing that's going to break, or get lost, or get stolen; I'll use it if it's free, though. I like PayPal's approach, they mailed out free SecurID dongles to anyone with a business account who asked for one. Mine still works fine on the original battery 10 years later.
Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
I agree, this is actually a "something you have" rather then a second something you know.
Almost everyone has a cell phone with free text messaging
Then I guess I'm not among "almost everyone", nor are other pay-as-you-go users in the United States market, which is Slashdot's home country. It's traditional for U.S. carriers to bill half the SMS toll to the sender and half to the recipient, and many SMS 2FA providers (such as those used by Twitter and Steam) can't make voice calls to landlines. To upgrade from pay-per-minute to unlimited would cost hundreds of dollars per year.
When plugged into a standard USB port
Aaaand I stopped reading as I can say with confidence 99% of people will never use it.
Just one of many problems - where do I put this on my iPad exactly? Or any mobile phone of any kind?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
What sort of man in the middle attacks do you envision the machine you're using will be able to perform between the dongle?
During the initial key exchange, when the U2F device sends its public key to the server, a man in the middle could substitute the public key generated by his own U2F device.
I don't keep my keys in my pocket, so I always have to go get my keys out of my bag when I want to log into my gmail, etc. I don't want the thing hanging around my neck, and not sure I want it on my wrist. How do you keep the darned thing handy at all times? I think I need a NFC yubikey type thing implanted in my hand.
Well I've got to hand it to them at least this isn't just another tired old token passing scheme running over TLS. There appears to be something "ChannelID"? I don't really understand the specifics that seems to bind something from USB card with the underlying TLS session.
Still I have three comments.
1. If your going to do this why not deploy client certs and have your card store private keys for each site and just push all responsibility for interface (special standard for pkcs12 download, user attention..etc) to the browsers. If you did that you wouldn't need ANY low level server side changes at all to take advantage of it and browsers would have more freedom to manage key storage.
2. Better to enter "what you know" into "what you have" than entering them separately.
3. The problem with all of these schemes is they are a single point of failure. Lose, forget to bring or break your USB stick and your fucked as a result. I don't expect very many sites that are not banks or something really important to even go here. Nobody is honestly willing to deal with both "I forgot my password" and "I lost my key".. so you'll end up with some sort of bypass like password questions that ruins the security of the system while making people "feel" secure because of all of these other worthless hoops they are going through.
I still think a better (as in practically useful across the board in line with what users and operators are willing to accept) approach to web security after an initial account creation step is use of secure password authentication protocols instead of the crap we have now where passwords are entered into adhoc web forms.
Teaching people to enter passwords only into specific dialogues in their browsers at least would provide some hope of some people not getting owned by all of the lame phishing shit out there. TLS-SRP for example provides secure authentication without requiring certificates or leaking material that can be used for offline attack rendering connecting imposter sites both harmless and easy to recognize and since authentication is used to encrypt the underlying session PKI is optional although recommended to provide privacy protection against disclosing user identity in the clear during handshake. The patches necessary to enable this continue to collect dust in many of the major browser vendors ticketing systems.
It is important to note that could happen, if the MITM defeats the SSL/TLS session, only while the user initially REGISTERS for the service. The public key is not sent each time the user logs in.
Look at this U2F NFC fob.
Not only that it KILLS anonymity, a basic human right for those who choose it and do no wrong with it.
First you have to BUY these things which is traceable.
Then they want you to use the *same* thing for all your accounts.
What a fucking joke!
Ever hear of The Federalist Papers, Bitcoin, or any other anonymous work of high import, influence, and so on?
All not possible without per instance anonymity and privacy.
One advantage of 2FA, is when they snoop on you, they can be more sure it is in fact you that they are snooping on. Same with finger print readers.
So what happens when you lose one of these things? Do you have to wait a week for a new one to arrive in the mail to access any of your accounts?
https://www.yubico.com/ - Yubico, the makers of Yubikeys, is the primary company and primary devices that Google, Facebook, Github, Dropbox, and others use. Reading the various comments here on Slashdot, I just want to quickly clear a few things up. Some think this is just a theoretical API. No, it is fully implemented, and the hardware has been on the market. I've been using my Yubikey for over a year now. The thing is fucking amazing. The key supports several different modes, so let's go through a few of them really quick to clear up concerns from above.
The type of authentication mentioned in TFA works by plugging in the USB key. After that, the browser makes a request to the key. The key then has an LED that starts blinking to indicate said request. The key does *NOT* process the request until the button on the key is pressed. The encryption key stored on the physical key also can NOT be read off of it at all, the device handles processing of the initial request. (yes, admittedly, this is slower than a normal CPU, it takes 1-2 seconds to process)
There are other modes, too. There is a mode which works exactly like Google Authenticator, where you can register 2-factor codes with it. The generated time based codes can then be read back either by USB or by NFC on a phone/tablet. This has the added advantage of the fact the seed for the time code is not retrievable from the device. The only thing the device will transmit out is the calculated time-based code. This has an advantage over Google Authenticator, where a compromised phone could easily leak the seed values and generate new time based codes. This calculation instead happens on the key, and only the final result is returned instead.
This device also works with PuTTY for SSH authentication. This is by *FAR* my most favorite feature. TortouseGit on windows also uses PuTTY for authentication, so this includes source code. You can pull out the public key from the device, and use the device to authenticate yourself anywhere that supprts SSH. I personally use this to authenticate into a cluster of servers that I manage.
This device includes a static password, too. Not everything supports these newer modes. There are a couple services that I use which dont. A randomized password up to 32 characters can be stored on the device, and with a single press of the button will emulate a keyboard and type it in. This is much MUCH easier than trying to type in long complex passwords which use tons of extended characters. But again, this caps at only 2 passwords (the device has 2 "slots" total, and other things such as the method mentioned in the article takes up 1 of those slots as well)
But pretty much every concern I've seen in the comments on this page are all directly addressedon the Yubico web site. These guys have thought of pretty much thought of every possible scenario imaginable. This isn't just some weekend project. This is a serious security product help designed and implemented by some of the largest tech firms in the world who have a serious stake at securing their own networks. The price for the keys are really not bad, so yeah, I'd personally recommend them.
The registering by phone *is* a form of two-factor authentication. You've just made the case for it. This is an improved form of two-factor authentication because it's too easy for phone numbers to get assigned to new devices. The SMS second-factor tends to work great against mass attacks and also protects low-value targets but is pretty much useless against a targeted attack. Too easy to walk into any mobile phone retailer and claim you lost your SIM card.
The problem with client certificates is that you have to install them on a device before using the device. So you can only login from a device you completely trust. This is just another form of something you know. It's not a second factor. With U2F you can, in a pinch, login from say a computer in the library and not worry that your certificate just got compromised.
I'd like to see them work with TPM which a lot of laptops have as well.
The problem with client certificates is that you have to install them on a device before using the device.
The browser can grab them from anywhere it can anytime it wants. It can also pass-thru cert validation to physical trinkets that look like USB sticks or credit cards the same as smart cards have been doing for ages.
So you can only login from a device you completely trust. This is just another form of something you know.
It's not a second factor.
No it is clearly something you have. Using trusted system is an implied baseline requirement. It isn't ever optional. This business of logging on from devices you don't trust = GIGO.
With U2F you can, in a pinch, login from say a computer in the library and
This limitation does not exist with my suggestion to just use client certs. There is no reason to assume browser is the entity that must offer a proof of possession to server. I just don't see the point of reinventing the wheel.
not worry that your certificate just got compromised.
Well there is that... I'm not sure what value this has to normal people who prefer criminals not transfer every penny out of their bank account or send all of their friends ransomware... but hey at least your certificate didn't get compromised.... hurray.
If you're seriously worried about someone hijacking your SMS/ph# you have bigger issues (ie., you've pissed off government or its contractors) and you need more than any multi-client 2FA can provide. For random hackers halfway across the globe, someone's phone # *is* out-of-band, and thus is a valid 'second factor' for auth.
Too many security-wannabee gurus take the threat model to its extreme: asserting anything other than the perfect Faraday-Caged un-cloneable device, DNA-coded-to-the-One-True-Owner is 100% useless. For a lot of people, simply having their phone get an SMS to verify something *is* enough to stop random Chinese Hacker 'Fu' from taking their email account.
The perfect is the enemy of the good. A lot of security tightwads need to realize that something is better than nothing for people who aren't under state-level scrutiny.
You should read the specification. The cryptographic handshake involved with a U2F authentication is quite ingenious. This goes way beyond yet another "something you know".
The protection against MitM and against phishing attacks is quite impressive and not something that any other second factors can do.
For account recovery, you should simply register multiple tokens and store them in a safe place. In fact, you could just give several of them to all your best friends. The tokens are useless without the password. So, your friends can't really do any harm. And if you lose your main token, hopefully one of your backup tokens is still to be found.
Basic tokens cost less than $10. And you can use a single token for an arbitrary number of sites and accounts. The super cheap tokens might not be ideal for every day use. But they're great for backup purposes
Can I use this on any computer, anywhere in the world, regardless of who controls it?
It takes one phone call to your mobile provider and a little bit of a sob story to have your cell phone number rerouted. You don't even have to be a high profile target. These days, crooks who prey on tourists and hotel guests have the expertise to launch this type of attack. Ask me how I know :-(
Just don't use SMS for important sites like banks, since it was hacked years ago. If someone knows you phone number, they can easily temporarily take over the phone number on their own phone and receive the SMS message, then release the phone number again.
That would be John Connor.
John Connor is leader of the Worldwide Resistance and last hope of humankind.
Congratulations, you've just described U2F!
The constitution does not gaurantee anonymity.
Isn't this what the yubikey is supposed to do? I mean it isn't exactly open but it does provide a nice easy 2FA.
A dead technology that never took off trying to gain mindshare based upon an unrelated Yahoo hack.
And yes, I could talk in much detail about all the words in the above sentence, but I can't.
Don't forget to log in with your Github.com account for 20% off!
I just ordered 2, these sound useful.
This really reads like an ad.
That's still something you know. You know the code. You aren't proving that you have the phone number - SMS is incredibly insecure, numbers can be rerouted to other devices, someone else could have your phone, etc.
No, you do not "know the code": the dongle knows the code.
In the case of SecurID there is no way for you to predict what the numbers will be, so you "know" them for only sixty seconds, after which you no longer know what they will be. With U2F, a key pair is generated and the private key never leaves the dongle. If a set or random bits (nonce) are sent to the dongle to sign, there is no way for you for you know what sequences of bits will be sent as the signed message.
A regular password is "known" because for a given username given as a 'query', you send back the known password. You cannot do this with dongles.
For SecurID you do not "know" what the 6+ digits will be at the time you log in, so you must have the dongle at time of authentication. For U2F, you do not "know" what the nonce that will be sent, so you cannot "know" ahead of time what string of bits to send back to authenticate yourself: you must have the dongle to authenticate.
The "knowing entity" is not you (the human), but the dongle. No dongle, no "knowing" for you. Therefore having the dongle is necessary.
Congratulations, you've just described U2F!
What I described is a smart card .. something that has been widely used for over a decade.
The difference in not reinventing the wheel with U2F is you don't need to modify servers to support experimental channel binding extensions. This can be deployed without modifying existing servers.
"Google is very much a not-invented-here, build it ourselves culture."
-Eric Schmidt
That sounds good to me. What that means, of course, is that the attack wouldn't work for a site you already have an account with (barring combining it with probably two other attacks, plus the MITM, for a total of four simultaneous successful attacks).
Which is a shame, because without the ability to publish anonymously, there wouldn't be a USA or a Constitution.
1) I access my email as much on my phone and tablet as much as I do my desktop. No mobile device support w/ Yubikey.
2) My laptop only has 2 USB ports, both of wich are already being used. Mouse & tethered phone (for internet access).
SMS is an attempt at "what you have", with lots of caveats.
Better than nothing - everyone has a phone. Not many people will buy dongles or tokens.
Instead it requires specialized hardware be deployed at each endpoint!
I got one of these 3 years ago and it stopped functioning after less than 3 months!!
You're simply wrong. It's just bits on the same wire. The fact that a typical user doesn't know the code without the dongle just means it's prone to failure.
It's no different than having your child type in 12 extra characters that you don't know at the end of the password you do know. You're passing off the knowing to someone or something else doesn't make it more secure, it makes it less so than if you had simply used a unique, random password.