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

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

fidoalliance.org

Post reply on HN
Print view View original

421–430 of 525 posts

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

#421

Post by lrvick »

xur17 wrote: post #130
vngzs wrote: post #71

Earlier quoted context omitted.

Right. Some core services get this treatment, like email and important online accounts. For others I rely on reset mechanisms tied to those email accounts if I lose the primary key and haven't had the chance to register the secondary. Every few months I'll sync up anything that has been missed. It's not perfect, but it's a hell of a lot better than TOTP.

I realize FIDO is better than TOTP since it prevents phishing attacks, etc, but as a user, the ability to backup my seeds is extremely convenient.

You can backup FIDO with BIP39 on some devices like Ledger.

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

#422

Post by lrvick »

xur17 wrote: post #127
michaelt wrote: post #65

Earlier quoted context omitted.

Eh, retrieving a key from off-site storage every time you open a new account is a pretty big inconvenience, even for a security enthusiast.

This. For a while I tried to keep a list of accounts I needed to add my offsite key to, and then every year or so I'd retrieve the key, and add in bulk, but that became way too complicated. While not ideal, I'd be happy if I could register with the public key of my offsite key or something similar. Really I think there should be a way to register a public persona, and add / remove keys from that persona at will. Or,…

You can generate duplicate FIDO devices with a shared seed right now. Hardware wallets like Ledger support this today.

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

#423

Post by lrvick »

bpye wrote: post #217
georgyo wrote: post #59

Earlier quoted context omitted.

It's actually horrible! Even key rotation is horrible! My yubikey is getting to about 10 years old, and I have replacements for it but find it very difficult to switch. It will eventually fail as an things do and it will be problematic. The problem is that I have several dozen accounts connected to it and I don't know all of them. So either I'm carrying and trying multiple keys at all times or not getting into a site…

I’m going to need to work this out soon. I picked up a pair of new YubiKey 5Cs yesterday with their sale. I’ve been using a YubiKey Neo for years for U2F, TOTP and GPG. Moving the GPG key is easy - though I might try using the FIDO2 support in SSH instead. However for every TOTP and U2F key I’m going to have to re-enroll the new keys… It feels like there should be a better way.

You can backup/restore FIDO2 keys via BIP39 on supported devices like a Ledger or Trezor.

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

#424

Post by nybble41 »

lxgr wrote: post #416
nybble41 wrote: post #398

Earlier quoted context omitted.

> … so the only thing that an authenticator could display on your screen is "do you want to authenticate as user x to website y" … That is exactly why you want it. Consider, for a moment, that you have a key which is used to log in to your bank account and some other, much less critical site. Perhaps a GitHub account where you store some hobby projects. Without an unforgeable indication on the authenticator to show w…

If you have malware on your computer (that can compromise the browser), it can just wait until you actually log in to your bank and then grab the session cookie/proxy away your authentication. It's a different story if the operation you are confirming with a security key actually can be rendered on the display, e.g. "pay $100 to someshop.com" (as in SPC [1]). In that scenario, there is actually nothing to steal excep…

> If you have malware on your computer (that can compromise the browser), it can just wait until you actually log in to your bank and then grab the session cookie/proxy away your authentication.

Sure, but you might never log in to your bank from this particular computer precisely because you don't trust it. But you think it's fine to log in to your hobby account since that doesn't store anything you really consider important.

If you assume there is never any malware on the host then you don't need the key at all—the host can store the secrets and handle the authentication on its own.

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

#425

Post by lrvick »

xdennis wrote: post #347
vngzs wrote: post #38

Earlier quoted context omitted.

You just register 2-3 keys. It's not so bad.

Why do people always say this? Do you not know how expensive they are?

Most people have smartphones which ship with WebAuthn so they are good to go. Granted phones are like $500+ so by contrast a Yubikey is a much cheaper alternative for a secondary backup device for most people.

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

#426

Post by lrvick »

throwaway52022 wrote: post #63
vngzs wrote: post #38

Earlier quoted context omitted.

You just register 2-3 keys. It's not so bad.

I keep an off-site backup at my parents house. Right now it includes a printed copy of my backup codes, so if my house burns down and everything is a total loss here, I at least don't have to start from zero. They live far enough away that my backup offsite backup can get to be a few months out of date but that's usually fine. (If I were to make a major change in something I'd make a special visit) I don't want to sp…

Use a Ledger or Trezor which supports backing up the random seed allowing you to backup all current and future accounts in one shot.

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

#427

Post by lrvick »

eMGm4D0zgUAVXc7 wrote: post #61
vngzs wrote: post #38

Earlier quoted context omitted.

You just register 2-3 keys. It's not so bad.

Do you only have 2-3 backups of your workstation? I have much more backups of my workstation etc., should I now buy dozens of crypto hardware key thingies and constantly switch them around to match the backup disks? For those who do offsite backups: Is an offsite backup possible across the Internet? Or do you have to physically drive the key to the offsite location? When I create a new account somewhere, does that me…

With devices that support BIP39 backups like the Ledger or Trezor, you are backing up the random seed that generates all possible future accounts deterministically.

Backup once, setup 100 accounts, lose authentication device, restore backup to new device, regain access to all 100 accounts. Easy.

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

#428

Post by jjeaff »

Kab1r wrote: post #381
_vdpp wrote: post #362

Earlier quoted context omitted.

How is that seed any different from a password then?

For one, it's only ever seen once: during initialization.

In addition, I believe it is not stored on the device. So it can't be exhilarated.

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

#429

Post by lxgr »

nybble41 wrote: post #424
lxgr wrote: post #416

Earlier quoted context omitted.

If you have malware on your computer (that can compromise the browser), it can just wait until you actually log in to your bank and then grab the session cookie/proxy away your authentication. It's a different story if the operation you are confirming with a security key actually can be rendered on the display, e.g. "pay $100 to someshop.com" (as in SPC [1]). In that scenario, there is actually nothing to steal excep…

> If you have malware on your computer (that can compromise the browser), it can just wait until you actually log in to your bank and then grab the session cookie/proxy away your authentication. Sure, but you might never log in to your bank from this particular computer precisely because you don't trust it. But you think it's fine to log in to your hobby account since that doesn't store anything you really consider i…

Oh, that's a good point – I personally never use my security key at untrusted computers, but I guess this could be a somewhat common use case.

> If you assume there is never any malware on the host then you don't need the key at all—the host can store the secrets and handle the authentication on its own.

True, a permanently plugged in authenticator is largely equivalent to just using a password manager (which also prevents against skimming, if used exclusively via autofill, never via copy/paste), but unlike a password mananger, it makes unsafe actions explicitly impossible for non-sophisticated users. I'd consider this a strong advantage.

It also survives OS reinstalls, ransomware etc.

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

#430

Post by lxgr »

zozbot234 wrote: post #367
lxgr wrote: post #331

Earlier quoted context omitted.

A much more secure way of doing this is to use the platform's/OSs most secure way of storing private keys, which in many cases is hardware (Secure Enclave on iOS, TrustZone or "real" secure hardware like Titan M on Android, TPM on Windows/Linux). This is already supported by many browsers (unfortunately Mozilla/Firefox are dragging their feet on this one [1]) and gives you exactly the user experience you want. [1] ht…

This does not solve the backup issue. It's effectively using the phone or computer as a whole as a hardware key, which introduces multiple failure modes compared to external hardware keys while also adding to privacy concerns. It might have some extremely niche use for some use of on-prem devices in enterprise settings where the inability to sever the authentication element from the actual hardware might be convenien…

The backup issue is solved by using an external authenticator for initial provisioning of new devices.

In a compliant implementation, you can add a new external authenticator from an existing trusted device, and a new trusted device from an existing external authenticator.

> while also adding to privacy concerns.

What concerns are you thinking about here?

> TPMs are essentially a misfeature given the existence of smartcards and hardware keys.

TPMs are essentially built-in smartcards (with a few other optional features like measurements/attestation, but these have never really taken off as far as I know, other than giving TPMs the reputation they have) and are very well suited for use as platform authenticators.

Post reply on HN