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

411–420 of 525 posts

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

#411

Post by nybble41 »

lxgr wrote: post #324
xur17 wrote: post #140

Earlier quoted context omitted.

Has anyone tried a Ledger or Trezor device for something like this? Your FIDO U2F private key is deterministically generated [0] based upon your seed phrase, which you can backup, and restore on other devices. [0] https://www.reddit.com/r/ledgerwallet/comments/udzx1c/ledger...

At least Ledger actually does support U2F as an installable application, but that's the predecessor to FIDO and has some weaknesses in comparison. I'm also not sure whether WebAuthN supports legacy U2F authenticators without the browser performing some protocol translation.

Ledger and Trezor both support U2F, which is a FIDO protocol but not the latest version. The Trezor Model T additionally supports FIDO2 (WebAuthn).

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

#412

Post by rad88 »

tialaramex wrote: post #380
rad88 wrote: post #243

Earlier quoted context omitted.

Yeah, well what I want is a (physical, literal) membership card like I have at the gym or library. I think "regular" people can learn to use USB tokens, and that they might make more intuitive sense than passwords. These places don't challenge me for the "secret password" when I come in, I just present or scan my card. It's very tricky obviously, in terms of engineering and operations, for an internet based company t…

As you will have seen in lots of other posts to this topic, people want privacy and "I just show my membership ID everywhere, what's the problem?" unsurprisingly is not what they had in mind. So, FIDO preserves privacy by minting unique credentials for each site where you use it. This is invisible to the user of course, for them it's just the case that you use your FIDO authenticator everywhere (that it works) and no…

I understand that. I was responding to the idea that hardware tokens like yubikey, in fact all alternatives to passwords, are too complicated for regular people to understand. And also saying that multiple options, to accommodate different people/scenarios, are fine and don't have to be complicated from the user's perspective. By way of analogy (admittedly I didn't make that very clear).

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

#413

Post by graton »

kayodelycaon wrote: post #221
graton wrote: post #191

Earlier quoted context omitted.

In each one of my PCs and also on my key-ring is how I do it.

If you sign up using one key, do the other keys work with that account? Unless it does, you're greatly increasing the complexity of creating new accounts anywhere. That's basically what I'm getting at. Do I need to do significant amounts of extra work to keep an off-site backup in another state?

I don't personally consider it greatly increasing complexity. At account creation I register the Yubikeys at the PC and on my keyring. When I first login from a different PC I use the Yubikey from my keyring to login and then register the Yubikey at this new PC.

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

#414

Post by lrvick »

MrStonedOne wrote: post #265
jupp0r wrote: post #157

Earlier quoted context omitted.

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

Yep! Just store your backup key in a safe-deposit box with your bank. Then go get it every time you sign up for a new account so you can make it the backup for that account then go store it again. and again. and again. and again. oh no! you lost your key! time to go to the bank to get your backup, sign in to all the accounts, remove the old key, register a new backup, oh wait, got to wait for the new backup to ship,…

There is no need for your described complexity.

More advanced FIDO devices like the Ledger allow you to backup the initial random seed allowing you to create a duplicate device from the backup any time you wish. No sites you signed up with will know or care that you swapped devices as the new device will generate identical keys via a deterministic KDF from the seed.

You can put this seed far away and would only ever need it when you wish to replace a lost or broken authentication device.

Aside: no US major banks issue safety deposit boxes anymore other than wells fargo which will stop issuing them soon as well.

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

#415

Post by lrvick »

zozbot234 wrote: post #156
aftbit wrote: 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.

Is this actually needed? Looks like the online part of this is just WebAuthn, which could be supported by the same tools we use for TOTP. You would "enroll" a visible master secret that you could then back up and optionally store in a hardware security key. The device itself wouldn't need to allow for extracting the secret again, because you backed it up at enrollment.

Ledger and similar hardware wallets support one time BIP39 backup covering all current and future accounts today.

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

#416

Post by lxgr »

nybble41 wrote: post #398
lxgr wrote: post #336

Earlier quoted context omitted.

This might be true for cryptocurrency transaction initiation, but in the WebAuthN model, what's the benefit of having a screen? The result of a WebAuthN challenge procedure is almost always a session cookie (TLS channel binding if you're really fancy), so the only thing that an authenticator could display on your screen is "do you want to authenticate as user x to website y", which arguably does not add that much val…

> … 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 except for the signed message itself, which would be useless to anybody that's not someshop.com, but given that WebAuthN almost always just yields a session cookie, I don't really see the benefit.

[1] https://www.w3.org/TR/secure-payment-confirmation/

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

#417

Post by nybble41 »

CyberRage wrote: post #175
stjohnswarts wrote: post #132

Earlier quoted context omitted.

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 l…

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

> Definitely the latter.

You sure about that? A properly generated (i.e. random) password won't be cracked or guessed in any reasonable amount of time, whereas a model of your fingerprint(s) can be lifted from any object you've touched and used to create a silicone mold capable of fooling many fingerprint readers. And you only have 10 of them at best; once all your fingerprints are known to potential attackers that's it; you can't use fingerprint authentication any more for the rest of your life.

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

#418

Post by lrvick »

throwaway52022 wrote: post #35

I've resisted switching to a hardware key because I know that I'm going to break it, and that seems like a huge pain in the ass. I really want to be able to make a couple of backup keys, or maybe put another way, I want to be able to put the private key on the device myself, I don't necessarily care that the key is generated on the device and never leaves the device. I don't care if that slightly reduces my security…

I have abused and soaked every model of Yubikey. I even melted the casings off every model with acetone to lookup chip specs and Yubico responded by switching to a new unidentified glass hybrid compound no common solvents seem to impact.

In all cases the Yubikeys still worked even as bare abused PCBs. You need a blowtorch or a drill to break one.

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

#419

Post by nybble41 »

jeroenhd wrote: post #263
dane-pgp wrote: post #232

Earlier quoted context omitted.

> Laptops and modern computers also contains a TPM The root of trust for which extends to who knows where, and you're not allowed to look at the source code or learn how it works because that would threaten Hollywood's profit margins. We're basically building a system of DRM for access to human beings, and making the whole world dependent on these unaccountable entities.

TPMs allow for arbitrary key storage by the operating system. They're not necessary for DRM. In fact, I've wiped my TPM several times to upgrade the firmware and I've had no trouble playing DRM content whatsoever. Technologies like Intel's management engine and SGX or their AMD/Qualcom/Apple counterparts are definitely problematic for user freedom in the way they're implemented. However, the TPM system itself is quit…

The user-hostile part of the TPM is the built-in key signed by the manufacturer which shows that it's an "approved" TPM which won't—for example—release any of the keys stored inside to the device's owner. This is what allows the TPM to be used as part of a DRM scheme.

If it weren't for that small detail then I would agree that TPMs can be useful for secure key storage and the like, working for the device's owner and not against them. The actually useful (to the owner) parts of the TPM do not require the manufacturer's signature.

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

#420

Post by lrvick »

michaelt wrote: post #65
vngzs wrote: post #38

Earlier quoted context omitted.

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

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.

You can use devices like Ledger that support BIP39 backup allowing you to create duplicate devices any time from a 24 word random seed.

Now your one time backup covers all current and future services.

Post reply on HN