Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Support for U2F security keys

blog.1password.com

Post reply on HN
Print view View original

141–150 of 164 posts

Re: Support for U2F security keys

#141

Post by ptoomey3 »

tptacek wrote: post #85
DINKDINK wrote: post #46

Earlier quoted context omitted.

>TOTP 2FA is already adequate to make sure you're not credential-stuffed. 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 t…

PAKEs are --- in this context --- simply a mechanism to authenticate with a password. They're phishable the same way an OTP token is. More importantly: they're irrelevant. No mainstream web application would be able to deploy them for the foreseeable future. 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 w…

100% true. I personally wish the hardware-focused U2F bit didn't predate the WebAuthn spec. I feel, because of that, way too much focus is placed on the "hardware security" bit. I view the main benefit as replacing user selected weak passwords with a non-phishable, non-server-side loggable, non-server-side sensitive secret needed authentication standard that can be implemented entirely by code, largely without user involvement, and that doesn't rely on gross failure-prone heuristics the way password managers do today. Oh, and it is all a better user experience too. It is one of those crazy wins that you just don't get in the security space that often. I really don't care if that takes the form of a hardware security key or as a pure software implementation in the platform browsers. My guess is we will strike a middle ground...with the dominant form of authenticator being hardware based...but that hardware taking the form of the devices you already own (phone, laptop, etc).

Re: Support for U2F security keys

#142

Post by ptoomey3 »

tpetry wrote: post #37
tptacek wrote: post #16

Earlier quoted context omitted.

The primary purpose of U2F/WebAuthn is to break phishing attacks. Code-based TOTP 2FA, the kind you're probably using now, is already adequate to the task of making sure you're not credential-stuffed.

Autofill of a password manager is a working countermeasure against phishing too: If autofill does not work there is something wrong and you should look closer...

My experience with password managers is that they work great for me, because I understand every sharp edge and can work around them. My experience when advising family to use them is that they invariably fail them and they get frustrated. Password managers rely on pretty gross heuristics to work. They are effectively trying to automate something built for a human (choosing, remembering, and entering a password). WebAuthn gives us a real API built by and for machines. This will make the flow much less error-prone and more secure.

Re: Support for U2F security keys

#143

Post by DINKDINK »

tptacek wrote: post #85
DINKDINK wrote: post #46

Earlier quoted context omitted.

>TOTP 2FA is already adequate to make sure you're not credential-stuffed. 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 t…

PAKEs are --- in this context --- simply a mechanism to authenticate with a password. They're phishable the same way an OTP token is. More importantly: they're irrelevant. No mainstream web application would be able to deploy them for the foreseeable future. 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 w…

>They're phishable the same way an OTP token is

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)

Re: Support for U2F security keys

#144

Post by burntsushi »

stingraycharles wrote: post #115
burntsushi wrote: post #93

Earlier quoted context omitted.

AWS at least lets you sign in using alternative methods if you get locked out: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credenti...

Which in itself is a problem: it means the MFA device is not required, if only they have access to my email + phone.

Sure, I know. Just pointing out that, at least for AWS, you do not need recovery codes or a second device for MFA. For me personally, phone+email is good enough for my threat model.

Re: Support for U2F security keys

#145

Post by jbergknoff »

charlietango92 wrote: post #78

only tangential, but I've wanted to carry my Yubikey on my keyring, but have always been nervous about making it unreadable by sullying the contacts. Should I be concerned about this? Where do you all carry them?

I came across https://www.thingiverse.com/thing:2588513 in some Reddit thread about this, got it printed on my public library's 3d printer, and it's been pretty nice. (Had to etch some grooves in the sides of the Yubikey so there's something to grab it to pull it out of the sheath, but that wasn't a big deal)

Re: Support for U2F security keys

#146

Post by mclehman »

lstamour wrote: post #70
Operyl wrote: post #59

Earlier quoted context omitted.

Which don't? For all the big major ones I've used U2F with, they've supported multiple keys for a while (or since introduction). It's practically a requirement in case you lose a key.. To name a few off the top of my head: Google, GitHub, Gitlab, Facebook, 1Password, etc.

Before this, both LastPass and 1Password said they supported U2F via Duo, but Duo only supported one key, so I could never use it.

If that's the case, it must have changed at some point. Lastpass and Duo both support multiple U2F keys, and have for at least a couple of years. I have two keys registered with Duo for login at my school and also through Lastpass's non-Duo U2F support.

Re: Support for U2F security keys

#147

Post by ecesena »

currymj wrote: post #25

I have long debated getting a Yubikey but have held off because I don't want to have to carry around several dongles at all times to be able to send an email. 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?

Given that you likely also have cable adapters and you need 1 primary key + 1 backup anyway, my recommendation would be to buy 1 usb-a and 1 usb-c.

Or you can make your own :)

iPhone/iPad is currently not solved, hopefully with iOS 13 we'll see positive news.

Re: Support for U2F security keys

#148

Post by ecesena »

packet_nerd wrote: post #129
tpetry wrote: post #37

Earlier quoted context omitted.

Autofill of a password manager is a working countermeasure against phishing too: If autofill does not work there is something wrong and you should look closer...

Unless DNS is compromised.

This also breaks security keys.

Re: Support for U2F security keys

#149

Post by ecesena »

bloopernova wrote: post #71

I'm seeing several links to different physical keys in the comments. Is there somewhere/someone that verifies these keys? Like a 3rd party testing/standards body? 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".

https://fidoalliance.org/

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.)

Re: Support for U2F security keys

#150

Post by dwaite »

mtgx wrote: post #139
cbhl wrote: post #56

Earlier quoted context omitted.

The way $dayjob makes this work is to issue a nano security key for each computer, and then a bluetooth security key for the iPhone (Android phones can use both NFC and Bluetooth security keys, but iPhones can only use Bluetooth security keys). 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 t…

NFC keys should work for iOS, too, now: https://9to5mac.com/2018/05/22/yubikey-neo-iphone-lastpass/

That is the Yubikey OTP functionality, not FIDO.
Post reply on HN