Live data from Hacker News

Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

fidoalliance.org

171–180 of 525 posts

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#171
post #148

Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? I would love to move from Username + Password + TOTP but my current workflow requires that I am able to regain access to my digital accounts using nothing but a few page paper backup including core service passwords & exported TOTP secrets.

Ledger (https://www.ledger.com) supports FIDO and lets you do backups. You really need a screen to do it correctly, otherwise there is little point in having an external device.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#172
post #148

Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? I would love to move from Username + Password + TOTP but my current workflow requires that I am able to regain access to my digital accounts using nothing but a few page paper backup including core service passwords & exported TOTP secrets.

Just so you don't feel alone with the replies being of the typical variety, I'm 100% with you. The flaws in the "backup token" approach are rehashed constantly but the world keeps turning as though they're irrelevant.

I look forward to hardware tokens reaching a popularity level where we see implementations in software and this conversation can be rendered moot.

Shout out to Mozilla and Dan Stiner for their work so far.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#173
post #77
post #55

The weakest link in security is always going to be humans. Account compromise is is more often a human problem than a technological one (spamming requests, password reuse, simple passwords, (spear) phishing, direct social engineering, etc). If I'm understanding correctly, they're aiming to reduce multi-factor auth back down to a single factor that's "easier" than passwords. Easier to use. Easier to social engineer a…

There's a frequent misconception that hardware keys are no better than, say, a TOTP seed on a secure element of your phone. The core practical difference between a hardware key and that TOTP code on a secure element is the hardware key, when registered with a domain, is programmed with the domain name in it. Lookalike domains - or anything besides the exact domain you registered the key with - fail to 2FA because the…

But this seems like a technological solution to a very human problem. If I can trick a user into approving the login, then hardware fobs, secure elements, etc, are meaningless.

The audience here is likely to assume that the security is solid. And it probably is. But this is a technology targeting your average user. It'll certainly be easier for the end user. But it seems like it introduces a human-based attack vector that may be easier to exploit.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#174
I fear services will force the use of certain devices, like those on the FIDO certified products list [0]. Will there be a way to use open hardware, open firmware, and user-controlled hardware attestation keys? Or will that be considered a fraud/bot risk?

[0] https://fidoalliance.org/certification/fido-certified-produc...

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#175

Earlier quoted context omitted.

But they are... Firstly, with how it works. even if you use the same finger to generate hundreds of keys, they should all be different because we are using noise\randomness within the algorithm itself. different sensors will generate different outputs and therefore it is pointless to worry about the key used stolen. I think what you want is secret keys completely detached from the user. we have that as well with hard…

Once they have a way to fake your biometric though they have it for forever, that's the point. With a password you have a way to provide a key only known to you and while it can be faked, it can also be reset, you can't reset your fingerprint without surgery

I don't get the point... If someone steals your fingerprint, he stole your fingerprint.

As I explained you can't get the fingerprint from the device\key, it is simply not there.

This isn't the problem of the implementation\technology if someone stole your fingerprint. it didn't lead to your biometrics compromised

What's easier to do? stealing someone's fingerprint or cracking\guessing their password.

Definitely the latter.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#176
post #157
post #148

Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? I would love to move from Username + Password + TOTP but my current workflow requires that I am able to regain access to my digital accounts using nothing but a few page paper backup including core service passwords & exported TOTP secrets.

Yubikey recommends a backup key for that very reason. Most providers allow you to register multiple keys.

"providers allow you to register multiple keys"

Why isn't my identity just a Merkle root? I don't understand the need to register individual keys.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#177

Is there any way to use this system without an extra device (no phone, no key, only my pc)? If not, is there a FOSS implementation of these required new devices? Maybe an emulator for one? Can I download an manage my own keys, manually? Can I self-host the authentication layers so I don’t need to use a 3rd party?

> Is there any way to use this system without an extra device (no phone, no key, only my pc)?

I've used rust-u2f in the past, although it seems to be Linux only. https://github.com/danstiner/rust-u2f

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#178
post #148

Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? I would love to move from Username + Password + TOTP but my current workflow requires that I am able to regain access to my digital accounts using nothing but a few page paper backup including core service passwords & exported TOTP secrets.

> Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? Why would you need that ? On most services that I use that support FIDO, you can register as many keys as you like. Seems to me that is a much more secure option than to provide a potentially exploitable option of allowing key extraction.

I want to avoid having to fetch my backup key every time I want to setup a new account. The backup key is kept offsite and thus inconvenient. It's offsite because that protects me from fire or other such catastrophic events.

This is what keeps me preferring password based security because I can backup my encrypted password database offsite with ease. Everything else provides hard path to recovery.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#179

Is there any way to use this system without an extra device (no phone, no key, only my pc)? If not, is there a FOSS implementation of these required new devices? Maybe an emulator for one? Can I download an manage my own keys, manually? Can I self-host the authentication layers so I don’t need to use a 3rd party?

> Is there any way to use this system without an extra device (no phone, no key, only my pc)? I've used rust-u2f in the past, although it seems to be Linux only. https://github.com/danstiner/rust-u2f

Thanks, I’ll check it out!

Looks like it answers some of my concerns. Super cool!

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#180
post #77

Earlier quoted context omitted.

There's a frequent misconception that hardware keys are no better than, say, a TOTP seed on a secure element of your phone. The core practical difference between a hardware key and that TOTP code on a secure element is the hardware key, when registered with a domain, is programmed with the domain name in it. Lookalike domains - or anything besides the exact domain you registered the key with - fail to 2FA because the…

Doesn't TOTP use current time as part of the challenge? Why couldn't a refinement of TOTP add the domain name as a further element?

If a user manually enters a code from TOTP device/calculator into a website, that TOTP device/calculator has no way to know which exact website domain it is - if the user visiting notmybank.com thinks they are visiting mybank.com, they'll get the right code for mybank.com from their device and get pwned.

The key part of FIDO protocol is that it prevents the user from getting the code intended from one domain and sending it to a different domain.

Post reply on HN