Support for U2F security keys
blog.1password.com
blog.1password.com
Surely other people are in the situation of:
- iPhone, iPad
- Macbook with only USB-C ports
- Windows/Linux workstation with only USB-A ports
Is there currently a non-cumbersome solution that will work on all of these?
I think the NFC ones are shipping after they worked out some kinks.
Details are available at https://security.googleblog.com/2019/05/titan-keys-update.ht...
I went with the Neo, because it supports all of my current devices, and for USB-C future testing, I tested it on my phone with an USB A-C adapter and it worked there as well. I'm a Linux/Android user without any Apple devices, though, so YMMV.
EDIT: Should also mention that I received a free basic Yubikey as a gift for subscribing to Ars Technica about a year ago. USB-to-MicroUSB and USB-to-C adapters worked on that for all of my devices, as well. I feel pretty confident switching to Yubikeys now that I have two and can keep the newish one on my keychain at all times, with the basic one in a secure place at home.
I don't think that's possible right now. Until they come up with a solution to "I've lost my 2fa token" that isn't as painful as losing you wallet there will be new designs coming out. (Actually, it's more painful. You only have a few cards in your wallet, while your 2fa token may be recognised by 100's of sites.)
This isn't a criticism of FIDO2/WebAuthn. I am impressed by how each iteration solves a new part of the problem, and FIDO2 was definitely a step forward, fixing rough edges in FIDO. But we aren't there yet. We need a FIDO3 and possibly 4, 5 and 6.
Assuming it's the "authenticate with either" solution, it ain't a great solution. If you have to replace a key you still have to visit every site you authenticate with and provide you new key. Looking at my password manager that seems to mean 100's of sites in my case.
There are lots of potential solutions to the "dog eat my token" that don't require me to visit every site I authenticate with - or even notify them. Online servers can even handle the "someone stole my token" case. Right now the only deployed online solution we have is OAuth, which really an authorisation mechanism. It sucks at for authentication.
It would be nice if someone made a library that made incorporating Webauthn login into an app as simple as using django or Ruby on Rails or React to create a login form, so folks don't end up rolling their own and assuming that a user will have at most one yubikey.
Failing that, you could do what Zeit does and rely on email providers' support for Security Keys (login by email link only).
To name a few off the top of my head: Google, GitHub, Gitlab, Facebook, 1Password, etc.
This still mitigates the most common MITM-type attacks:
1. Attacker instigates login via fake portal.
2. Attacker fools you in to entering your 6-digit OTP.
3. Attacker intercepts your valid OTP, combines with your stolen password, logs in to real site.
This doesn’t work with a YubiKey or the equivalent because of the back-and-forward cryptographic signing. The request has to come from the website you’re logging in to, which it doesn’t in this scenario. It’s the weakness of part 2 above which we avoid here.
By using multiple keys, you are effectively removing that advantage: someone could have one of your devices (e.g. your laptop while you're out for lunch) and would be able to make use of your second factor without you knowing.
It's cumbersome, but less so than when we were plugging and unplugging our one hardware USB-A OTP token into everything (and using a desktop web browser to generate OTPs for the phones).
If you do end up getting a security key, I recommend getting at least two. If one fails, you'll want the other one as a backup so that you can get back into your accounts.
You’d then have to contact support to let you bypass 2FA, but if that’s possible then the 2FA protection is weak, prone to social hacking.
By the way: I recommend getting the larger keys, not the nanos. These nanos look cute, but especially the newer ones are intended to be fixed to one device permanently, which in my opinion is both inconvenient and not the intended usage.
I wonder if iPad apps will start supporting Yubikeys — especially with the new iPad pros and their USB-C port it seems natural.
Ideally, I'd love to see Blink integrate ssh-agent, gpg-agent and its card support, which would let me use my existing (excellent) setup for using GPG keys stored on a Yubikey for ssh (see https://github.com/drduh/YubiKey-Guide for a great writeup of this approach).
Similarly, my laptop has an SD card reader and Ethernet port. My laptop and phone have 3.5mm jacks. All my small devices use micro-USB.
No dongles or adapters makes for seamless usage. I guess the only 'adapter' is keeping a micro-USB -> USB-A cable around.
Or you can make your own :)
iPhone/iPad is currently not solved, hopefully with iOS 13 we'll see positive news.
Humans are bad at giving up. If there seems to be a way forward for the original plan they will press on, regardless of all indications that this now a bad idea. In fact Google had a security override in Chrome for years that was literally typing the sequence "badidea" in recognition of this. It's not specific to computer security, it happens in incident management, there's a seminal example from years back where a train breaks down, and the incident manager sees that step 1 of the response is to send a recovery train to the location, and literally _hours_ later, with passengers stranded and desperate - that manager was still wrestling with how to get the recovery train to the location so they could proceed to step 2, rather than realising that problems with the recovery train meant they needed to _abandon the entire plan and re-assess_ because humans are not good at that.
Are you saying that a phishing attack can be executed against U2F/WebAuthen if the attacker controls DNS?
PAKEs provide defense against both credential stuffing, (some types of) phishing/MITM, CA trust etc without UX cost (a security solution that "Just works" for users with security apathy. U2F defends against compromised user space (PAKEs would fail to protect against a key logger) and require more onerous exfiltration (either physical theft of the device or biasing the U2F keys/functions)
Wiki's:
https://en.wikipedia.org/wiki/Password-authenticated_key_agr...
https://cryptowiki.net/index.php?title=Password-authenticate...
Blogs:
https://blog.cryptographyengineering.com/2018/10/19/lets-tal...
Nerds like talking about how their login secrets are protected in hardware with Yubikeys, but that's not the reason why big sites deploy U2F tokens. U2F tokens were standardized and adopted as a phishing countermeasure.
Accurate point and why I caveat the malware/phishing point with (some types).
>U2F tokens were standardized and adopted as a phishing countermeasure.
U2F provides benefits over TOTP besides phishing
-TOTP seed generation may be compromised/bad at authentication point, may not be deleted, TOTP-seed may be shared with Eve
-Smaller exfiltration profile: When producing a U2F proof, user space isn't doing computation that could be exploited. TOTP clients generate excessive secret data for the necessary task:
User: Hey computer, I need a TOTP to log into my Vintage-Car forum.
Computer: Ok! I'll go ahead and compute the TOTP secrets to your bank, bitcoin wallet, SSH keys, and literally everything else in addition to your Vintage-Car forum account. Hopefully no one's shoulder surfing you or I don't have malware!
I think it's PAKEs are a huge win for high security-apathy users but there are trade offs: -User space has to run more code
-All user-space platforms need to be able to run PAKE code, or else all the (non-phishable, non-server-side loggable, non-server-side sensitive..) benefits go away
-Low-entropy password choices can't be prevented server side (guess this functionality could be wrapped into the client-side code)
That's backwards. TOTP is vulnerable to phishing attacks, which are the primary threat model. Far better to use U2F for daily use, and then keep a printout of the TOTP QR code in a safe at home as a backup.
https://solokeys.com/collections/preorder/products/copy-of-s...
[1]: https://www.yubico.com/wp-content/uploads/2018/09/yk5-diagra...
Bitwarden has been fantastic, I highly recommend it.
Bitwarden is free as in a beer and free as in speech. Only if you want the 2FA features you need a subscription.
Then Bitwarden costs 10 USD per year. That's approx as much as 1Password asks for 3 months. Ie. Bitwarden is almost 4 times as cheap.
For that price you get a very good program with an open source frontend, and an open source backend (third party, in Ruby).
And Lastpass, after they were acquired by LogMeIn, has the balls to go from 12 USD/year to 24 USD/year. Without any additional features whatsoever a 100% price increase? That's why I went shopping. And I ended up at Bitwarden.
Our apps do not currently support U2F/WebAuthn when signing in, so they'll default back to TOTP based until we implement support for U2F. We aren't making any promises as to when this will arrive but at least two of our apps now have some form of support for it internally. It's far from complete and not ready for users but it is being worked on.
Note that U2F in this case is only about authentication, not decryption of data. This is why it's only used on initial setup of your account on a new device. The cryptography side for unlocking 1Password is entirely independent of U2F/MFA.
Hope that helps but let me know if you have any questions.
Kyle
1Password
> Last year we added two-factor authentication to provide another layer of protection for your 1Password account. When this is enabled, you are prompted to enter your second factor any time you sign in from a new device.
If you read it carefully, you'll have the answer to your question.
Thus far it's just Dropbox and Gitlab that I use it for, since they're among the few services that allow multiple 2FA methods to be used at the same time.
edit: I guess the thread is referring to multiple fallbacks that aren't U2F, but even still, if you're relying solely on U2F it's good practice to have more than one key lest you lose it and get locked out.
I keep keys in separate locations for safety, but that makes adding all keys to a new account a big pain.
This hasn't been a big problem yet because there are so few services that support the keys, but I wonder how people would manage it if it became widespread.
What I'm going to do personally is only use U2F on my most secure services (email, 1Password itself, GitHub). 1Password with the TOTP stored inside of it should be good enough for the others.
For storing TOTP keys on your YubiKeys, those must be the same, so you probably have to add them at the same time, or take a picture of the QR-code before you complete the registration.
The challenge is remembering to enroll using your backup device. Also, ideally your 2 devices would never be in the same room as each other, otherwise you are at risk of something like a fire destroying both.
Ideally there would be a way to enroll the second device without possessing it, but I'm not sure that's technically possible.
It's as simple as clicking the button to add another, and walking through the steps. Just be sure to name them in such a way that you can tell them apart. I typically use the identifier on the key itself. It's usually printed somewhere opposite the USB contacts.
Kyle
1Password
They have all worked with Yubico U2F keys and with the Google Titan keys. Pretty convenient way to have two factor authentication. I like the Yubikey 5 Nano as you can leave it plugged into a port in your laptop all the time.
I've run into a number of services that only allow a single U2F key (it's been a while, so I don't remember the exact ones). Even if they do support multiple U2F keys, how do you handle enrolling both? I keep my backup key offsite, so ideally I could enroll it without physically possessing the device. If I have both in my possession at all times (or even sometimes), I'm at risk of losing both of them.
AWS and Twitter are two services which only allow a single U2F device.
I've always had it drilled into me that doing crypto yourself is fraught with peril. It seems that doing hardware would be doubly dangerous. I'd want more verification that the implementation is correct and "strong".
What you might want to look at is things like hardware hardening or side channels. (Whether or not you consider this a matter of "correctness" can be argued, but here I would consider correct = implements correct algorithm.)
I think attacks against U2F devices are fairly difficult because you can't really use them as any kind of oracle, just due to the way the user interface works. But I am not a crypto expert, I just know how U2F works.
https://www.yubico.com/products/yubikey-fips/
These are validated by NIST (National Institute of Standards):
https://csrc.nist.gov/Projects/Cryptographic-Module-Validati...
Note that most keys are level-1 certified, i.e. against online attacks. Physical attacks are generally not much important, because if an attacker has access to your key, he can simply use it. (unless you went through the additional hassle to set a pin, but very few people do it.)
When you launch you'll be prompted to purchase. On the screens near the bottom there is a line of text about purchasing a license, go that route instead of signing up for the 1Password.com service.
Kyle
1Password
Where can I see product info about the licensed version? Can you provide a link?
> Or, to purchase a standalone license, click “Need a license? We have those too.” After purchasing your license, add it to 1Password.
> Or, to purchase a standalone license, click “Need a license? We have those too.”
[1] https://support.1password.com/upgrade-windows/ [2] https://support.1password.com/upgrade-mac/
Edit: I've literally had this belief for years, and I absolutely love their product. I'm the classic case of the user that's already decided to purchase and all they need to do is take my money, but I gave up. Searching produced a forum post where there was a litany of users who were thoroughly confused about the availability of the licensed version, as well. We are clearly not alone.
"So while it works great as your second factor in those browsers, for now you’ll still need an authenticator app set up to use with the 1Password desktop and mobile apps (and any unsupported browsers)"
Adding 2FA to it is great but I think the best security is likely still just to sync and use local apps for this data, to avoid being exposed to any JavaScript vulnerabilities or if 1password.com were ever hacked.
For instance, if you aren't using the browser extensions, how are you getting your password to the browser to sign in? Copying and pasting? It's possible for any app on your system to read the clipboard.
Drag and drop should be a better alternative there, as we now support that in 1Password 7.
The extension though uses either Safari App Extension (for Safari, obviously) or Native Messaging Host (Firefox and Chrome browsers) and aren't susceptible to clipboard type snooping.
The browser extensions also only present items that match the website you're on. This helps a lot in phishing attempts.
So, yea, you could not use the browser extensions but you're going to have to trust that YOU always do the right thing.
Note again that 1Password does not "auto fill" like other password managers, where simply visiting the site fills the data in. You always have to explicitly ask 1Password to fill into the page.
Just some insight anyway.
Kyle
1Password
I have a "vault" (1password's term for an encrypted file containing passwords and related info) that's sync'd across devices through dropbox (and accessed through a locally installed app), which I think is what you're suggesting.
Anyway, I think there's no particular need to access passwords through the site.
I'd definitely feel uncomfortable typing my 1password vault password into a web page or anything else besides the apps.