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

What I Wish I Knew About U2F and Other Hardware MFA Protocols

goteleport.com

Post reply on HN
Print view View original

21–30 of 95 posts

Re: What I Wish I Knew About U2F and Other Hardware MFA Protocols

#21

Post by girvo »

BoppreH wrote: post #15
sly010 wrote: post #14

Earlier quoted context omitted.

Buy 3 keys. Register all of them to your account. Then register all of them to your spouses account too. Put one on your keychain. Put one on your spouses keychain. Put one in a safe place. By enrolling my spouse and cross registering all keys, both of us are safe. We might loose our keychain, but we will always find each other, even when we are traveling. This works for Google and GitHub, but not every service allow…

Doesn't that mean that stealing any of the 3 yubikeys means full permanent compromise of all your and your spouse's account? I think a good with system should include some sort of revocation, like a master key you can keep in a safe to revoke other devices.

They need my password too, so they’ll have to have cracked my 1Password account as well. My third key is indeed in a safe, but it’s not special in any way.

Re: What I Wish I Knew About U2F and Other Hardware MFA Protocols

#22

Post by jackson1442 »

BoppreH wrote: post #20
cronos wrote: post #19

Earlier quoted context omitted.

You can un-register any of the keys when you're logged in. So if you lose one key, log in using the others and remove it. No need for a master key.

Your idea works well for recovery. But I'm thinking of a revocation scenario, where a key is stolen. In that case the attacker can just remove your keys first.

Yubikey still acts as a second factor, so for the average person's threat model this should be fine provided you use strong, unique passwords for your accounts (i.e. a password manager). 1Password supports U2F as a second factor to access your account, but you still need to know your secret key and master password; you cannot decrypt your vault with only a hardware token.

Re: What I Wish I Knew About U2F and Other Hardware MFA Protocols

#23

Post by ecesena »

christiansakai wrote: post #8

For a noob like me, I am thinking to get a Yubikey. What will happen if I lose my Yubikey? Am I essentially out of luck assuming the admins can’t reset my password or associated yubikey device? How do I prevent such scenario from happening? Is there truly a fool proof way of hardware authentication?

When you enable 2FA with security keys you have 2 options, let's call them the easy and the strong.

The easy. Add both a security key and OTP (e.g. Google Authenticator). You have 1 rule to strictly adhere: if you click on a link, you MUST use the security key, because that's the one that protects you against phishing. When you don't have your security key, you can just use OTP provided that you typed the url and not clicked on it from email/text.

The strong. You enable 2+ security keys. You keep one in a safe at home. You always use a security key to sign in. On your Google account you can also enable Advanced Protection, that's essentially this plus some extra restrictions to API access.

Re: What I Wish I Knew About U2F and Other Hardware MFA Protocols

#24

Post by wahern »

cronos wrote: post #18
scott00 wrote: post #12

I thought PKCS#11 was exactly what the author wanted: an API for performing arbitrary sign and encrypt operations using a hardware protected key. What doesn't it do?

PKCS#11 is a C API. It does not describe the wire format for talking to the actual hardware. To use PKCS#11 for a particular device, you need a module (shared library) to translate between the C API and the actual hardware. This module is usually vendor-specific. If I develop software with PKCS#11 support, I'm basically asking every user to find a PKCS#11 module from their device vendor and install it in the right pl…

The wire format is standardized: ISO 7816. Even U2F uses ISO 7816.

This issue with existing smart card technology is not lack of standardization, it's too much standardization--too much flexibility and stacks that are too deep.

Vendors ship their own PKCS#11 drivers as a convenience. But PKCS#11 isn't the only high-level API. The other is PC/SC, which is actually simpler than PKCS#11, though it often requires more local support from the OS. But not necessarily. You can write PC/SC shims that talk directly to hardware, or even to Vault servers if you want, w/o OS support. I have my own rapid driver framework that supports all of these. For example, I have a PKCS#11 and PC/SC client driver which can use the Apple T1 chip to authenticate to a Vault server for remote signing using Transit keys--the only engine that supports ad hoc remote key operations. This permits sharing GnuPG (via PC/SC) and OpenSSH (via PKCS#11) keys between users, without actually disclosing the keys, though Vault actually makes it difficult to do this securely as you need to write ACLs to prevent transit keys from being exportable.

BTW, you don't need special drivers to use Yubikeys, either. They just provide them as a convenience because the FOSS ecosystem is confusing and... non-optimal.

I'm hoping to release a macOS product soon and as part that may release some of my framework as FOSS.

Re: What I Wish I Knew About U2F and Other Hardware MFA Protocols

#25

Post by thomashabets2 »

> TPMs are soldered onto motherboards so they are not portable. Like U2F, they also don’t let you sign arbitrary data.

Incorrect!

You can use TPM chips to RSA sign arbitrary data, and use that to authenticate SSH:

https://blog.habets.se/2013/11/How-TPM-protected-SSH-keys-wo...

Even under Windows: https://blog.habets.se/2016/10/Windows-SSH-client-with-TPM.h...

The secret is using TSS_HASH_OTHER as the hash algorithm, which tells the TPM "it's already hashed". Whether it actually is hashed, or just raw input, is up to you.

Re: What I Wish I Knew About U2F and Other Hardware MFA Protocols

#26

Post by CameronNemo »

loloquwowndueo wrote: post #7

A tomu ( https://tomu.im/tomu.html ) can be used as a U2F device. Since it’s hackable and the code for U2F is available maybe it can be adapted as the author was asking (do you know of a device...?)

https://www.crowdsupply.com/solokeys/somu

Re: What I Wish I Knew About U2F and Other Hardware MFA Protocols

#27

Post by thatnerdyguy »

sly010 wrote: post #14
christiansakai wrote: post #8

For a noob like me, I am thinking to get a Yubikey. What will happen if I lose my Yubikey? Am I essentially out of luck assuming the admins can’t reset my password or associated yubikey device? How do I prevent such scenario from happening? Is there truly a fool proof way of hardware authentication?

Buy 3 keys. Register all of them to your account. Then register all of them to your spouses account too. Put one on your keychain. Put one on your spouses keychain. Put one in a safe place. By enrolling my spouse and cross registering all keys, both of us are safe. We might loose our keychain, but we will always find each other, even when we are traveling. This works for Google and GitHub, but not every service allow…

That's all well and good, but a few weeks later I have another service I'm going to sign up for... I have to... first go to my safe deposit box to grab my third key? If I don't, then seems like it's a lot of bookkeeping.

Re: What I Wish I Knew About U2F and Other Hardware MFA Protocols

#28

Post by EvanAnderson »

scott00 wrote: post #12

I thought PKCS#11 was exactly what the author wanted: an API for performing arbitrary sign and encrypt operations using a hardware protected key. What doesn't it do?

I thought that too. The Nitrokey HSM would do what he's looking for, except that it's exposed as a PKCS#11 module.

Re: What I Wish I Knew About U2F and Other Hardware MFA Protocols

#29

Post by shaicoleman »

Does anybody know if there is a U2F software solution that works with mobile phones?

Ideally with the following features:

* Stores keys securely in the Hardware-backed Keystore

* Authentication via fingerprint + periodically via password

* Allows to backup the secret key during setup

* Supports multiple devices

* Open source

* Works over Wifi

* Works with Linux desktops and Android phones

Re: What I Wish I Knew About U2F and Other Hardware MFA Protocols

#30

Post by pvg »

thatnerdyguy wrote: post #27
sly010 wrote: post #14

Earlier quoted context omitted.

Buy 3 keys. Register all of them to your account. Then register all of them to your spouses account too. Put one on your keychain. Put one on your spouses keychain. Put one in a safe place. By enrolling my spouse and cross registering all keys, both of us are safe. We might loose our keychain, but we will always find each other, even when we are traveling. This works for Google and GitHub, but not every service allow…

That's all well and good, but a few weeks later I have another service I'm going to sign up for... I have to... first go to my safe deposit box to grab my third key? If I don't, then seems like it's a lot of bookkeeping.

You don't need to make it as elaborate as 'safe deposit box' or 'implanted into spouse' and most accounts that matter have other ways of recovery, e.g. an app-based authenticator, one-time recovery codes (a recovery code is something you might want to stick in a safe deposit box). You can just get, say, three hw keys, put one on a keychain another somewhere on your desk and a third in a drawer somewhere.
Post reply on HN