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
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
"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.
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?
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!
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.
Presumably the U2F key is more hardened against key extraction attacks than, say, someone with physical access to your machine and your user account's .ssh folder.
It works with Bluetooth and NFC, as well.
It little behooves the best of us to comment on the rest of us.
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.
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.
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?
The keys have a physical button on them an an LED. the LED starts flashing when the browser makes a request, and to authenticate, the user MUST press the button for the embedded circuit to process the encryption request.
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.
Which is still way better than single-factor authentication
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.
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.
I'd have gone with:
Your account are all belong to us.
Something between the lines jumps out and bites your arm off. Soltan Gris / London
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 :-(
That would be John Connor.
John Connor is leader of the Worldwide Resistance and last hope of humankind.
Congratulations, you've just described U2F!
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.
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.
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).
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!
Of course. I have a machine right over here you can use to access your most important accounts, files and data. Feel at home.
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.