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."
A "second factor" presented as bits along the same wire as the bits of your password is not a second factor. They're both something you know. The only difference is you can lose the dongle and be fucked. You're still vulnerable to being phished or MITM'd or logging in via a pwned box or whatever else. The only thing time-based 2-factor approaches protect against is your own stupidity (reusing passwords or using bad passwords) and getting phished by a passive attacker who won't be using your credentials immediately.
We're already seeing what happens when people have multiple dongles to deal with - they want one dongle to rule them all, or one app that holds all the seeds to generate the keys for each site/service. This is the same thing as password reuse. If the app or dongle is hacked, you're fucked. We've also already seen the trusted, extra secure 3rd parties that hold the secret seeds for those "2 factor" solutions get hacked.
First, the app name is Google Authenticator. Second, it works with more that Gmail, I have my DNS provider, my GitHub and GitLab accounts, my Google accounts, my corporate accounts, etc all inside that application. It works on more that one site because they all support TOTP, an open algorithm, that is what the app, and many other alternatives like FreeOTP.
About what is better is the USB device that an application? The keys are stored on the device, and good devices are designed so keys are unreadable outside of it, only the generated code. Applications are vulnerable to malware on the device running it. The device ideally is less vulnerable of malware, it will be able to intercept current generated codes, but not extract the keys and generate codes themselves (unless the firmware is too buggy that it exposes the keys to the host device)
Linux? Yes!
I use these on Linux, MACOS and Windows for all my Github and Google accounts.
https://www.yubico.com/github-...
See the FIDO U2F Security Key.
You're still vulnerable to being phished or MITM'd or logging in via a pwned box
You can't be phished because the phishing site won't have the private key of the original website to validate to the key-dongle you are making a request to it from the original website that was stored when setting up the authentication originally.
You can't be MITM'd as as vulnerability any different than SSL traffic. The keys won't match to decrypt the traffic, which were exchanged originally when setting up the authentication.
Of course the encrypted data stream can be logged from a MITM position, just like SSL traffic now, but the idea is the attacker doesn't have either key to decrypt it to plain text and shouldn't have a quantum computer to brute force it in any reasonable time.
Logging in via a pwned box would only be able to intercept that session.
So yes, that can be quite damaging in some cases, but doesn't grant the attacker continued access. Remember, you need to push a button on the hardware dongle to reply to an authentication request and this request is only valid for the one session.
For situations like say banking, yes one session is enough to have your account drained.
But I fail to see how this is any WORSE off than not using the hardware key, while it is clearly still BETTER than not using a hardware key because it solves 2 of the 3 situations you describe.
You are falling for the typical error in assuming a replacement security function must somehow be 100% effective else it is worthless.
In reality, it only needs to be more effective than what you were previously doing to have some value, and you are ignoring that fact.
If it was only 1% better then you may be valid in claiming the time investment of switching may not be worth it.
But with the examples you listed it is clearly more than 66% better (2 of your 3 conditions are solved problems, and of the 3rd condition it is at least slightly mitigated even if not fully or even mostly)
The sites give you 10 temporary one-time keys to use, designed to be printed out and stored in a lock box. These are used for emergency access when the physical device is unavailable.
You generate your own key.
Logging in from a pwned box will get your one account stolen. But it's not a profitable criminal enterprise since it's a retail theft. This prevents wholesale crimes. Somebody can also rob you and steal your U2F dongle and threaten your family with violence if you don't turn over your dongle and password. It prevents mass attacks.
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.
They can generate application specific key but the firmware is closed so one does not know what they do. They may make it so that the key recoverable in short time for them. Only the server side source code is open. I would not trust it much.