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

391–400 of 525 posts

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

#391

Post by blibble »

jeroenhd wrote: post #350
sdfgdfgbsdfg wrote: post #343

Earlier quoted context omitted.

Yes but what the OP is saying is that the TPM does not store the encrypted passkey, rather, the passkey is wrapped with this TPM's public key by another TPM that already trusts this TPM, so this TPM can import a passkey that's been wrapped with its own public key and store it unencrypted. See Apple's circle of trust: https://support.apple.com/guide/security/secure-keychain-syn...

I understand that, but that's not supported by any current standard as far as I know. We'll need a new TPM standard for this, which probably also means it will take years before every device supports this feature as modern computers can easily last five to seven years if you replace the batteries and don't cheap out. FIDO needs something that works now, or maybe tomorrow.

you can do it easily enough with the current TPM operations (2.0, not 1.2)

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

#392

Post by tialaramex »

amf12 wrote: post #373
snarf21 wrote: post #256

Earlier quoted context omitted.

I wish FIDO was built into the phones (enclave) requiring a biometric and passcode. For 99% of users this would be superior to email/password and get rid of a lot of hacks/phishing. It doesn't require extra hardware to buy and simply requires a minor protocol update to have the challenge on a laptop/desktop show as a QR-code (or could be sent via BT). The mobile sends the response out of band to a destination set at…

> I wish FIDO was built into the phones (enclave) requiring a biometric and passcode Pixel 6 supports this (Titan Security Key built-in) , but only works with Google accounts I think. I hope more phones support this.

Not just Google accounts, most Pixel phones (I think I have a Pixel 2 here) do WebAuthn. I use it for GitHub (occasionally) and my private pastebin setup which is WebAuthn protected for ease of use - and I could use it for Facebook (but I never book faces on my phone) and other services.

One bonus feature does need the Google account. If you're signing into say banana.example with WebAuthn, using Chrome on a PC, and Chrome can't see any FIDO authenticators plugged in, it will try your phone! It asks Google, hey, does this user have a phone (Chrome is signed in to your Google account) ? Google says yeah, they have "amf12's Pixel 6". The Chrome browser uses Bluetooth on the PC to say "Hey, amf12's Pixel 6 are you out there? Can you do WebAuthn?" if your phone hears the Bluetooth message it's like "Hi, amf12's Pixel 6 here. Standing ready to do WebAuthn" and then via the Google servers it's arranged that your login attempt on Chrome, on the PC, is proxied to the phone, where it appears on screen ("Do you want to log in to banana.example as amf12?") and you can OK that from the phone. Nice work flow actually, although the technology is remarkably complicated.

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

#393

Post by blibble »

jeroenhd wrote: post #337
blibble wrote: post #325

Earlier quoted context omitted.

> Secure boot with just the MS keys is quite silly and ever since that one version of Grub could be exploited it's basically useless this isn't true: there's a hash blacklist which is (supposed) to be regularly updated by your OS update mechanism windows update does it anyway

Is there a way to list this blacklist? I have several computers which haven't received updates in years and I strongly doubt that the internal blacklist has been updated.

mokutil --dbx

official list is here: https://uefi.org/revocationlistfile

(I have my own root configured for all of my machines so only stuff I've signed can boot)

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

#394

Post by [deleted] »

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.

[deleted]

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

#395

Post by lrvick »

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.

Hardware wallets like a Ledger allow you only once, on initialization, to backup the initial random seed to paper in the form of 24 english words via the BIP39 standard.

You can use this seed by hand or on a duplicate device to deterministically recreate all keys be they webauthn, pgp, bitcoin, or otherwise.

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

#396

Post by adrian_b »

_vdpp wrote: post #375
adrian_b wrote: post #349

Earlier quoted context omitted.

The ability to have a backup does not imply any ability to exfiltrate the master secrets. It is enough to have a means to wipe out any information contained in the device, including any master secret. At that point, there should be a means to enter a new master secret in the blank device, before proceeding to use it normally. If a device provides this feature and it does not contain any other secret information intro…

If I’m the one entering the master secret in, then the device is a glorified password manager. The point of an HSM is that nobody, not even the user, can access the secrets. I’m not saying there isn’t a use case for such a device, or that it isn’t possible, only that the security guarantees you get from it are different. The security model you’re describing is the same as someone entering their secret key in the “not…

The device that you name "HSM" is the kind of device that is suitable for a company to distribute to its employees to login into the company network or servers.

It is not a device useful to have for an individual user. On the other hand, hardware password managers are useful for individual users.

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

#397

Post by lrvick »

_vdpp wrote: post #362
TacticalCoder wrote: post #359

Earlier quoted context omitted.

> I think the whole point of HSMs is that you can’t back up (read: exfiltrate) the master secrets. You're getting it backwards though. You are right that the whole point of an HSM is to not leak secrets when connected to a compromised computer. However there's nothing wrong with a HSM device that can be initialized with a "seed" of your liking, as long as that initialization step is done in a fully offline / airgappe…

How is that seed any different from a password then?

It never comes into contact with the memory of a network connected system, therefore putting it beyond the reach of phishing or malware thus solving the overwhelming majority of risks actual passwords are exposed to.

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

#398

Post by nybble41 »

lxgr wrote: post #336
pat2man wrote: post #171

Earlier quoted context omitted.

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.

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 what you're logging in to, malware can wait until you're logging in to the second site, and thus expecting a prompt to use the authenticator, but actually trigger the authentication process for your bank off-screen. You tap the button or whatever on the authenticator thinking that you're logging in to your GitHub account but actually all your money is being siphoned off to who-knows-where.

A key that signs whatever request is presented to it without any indication to the user of what the request actually was is dangerous.

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

#399

Post by lrvick »

andrey_utkin wrote: post #237
traceroute66 wrote: post #158

Earlier quoted context omitted.

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

You cannot register more than one security key with *AWS*. Which a lot of devs beg for, for years. Can't find that support ticket URL now.

To work around this I sync multiple Ledger devices with identical seed phrases which allow for duplicate FIDO devices that can be shared with any teams that need break-glass root account access.

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

#400

Post by _vdpp »

zozbot234 wrote: post #379
_vdpp wrote: post #375

Earlier quoted context omitted.

If I’m the one entering the master secret in, then the device is a glorified password manager. The point of an HSM is that nobody, not even the user, can access the secrets. I’m not saying there isn’t a use case for such a device, or that it isn’t possible, only that the security guarantees you get from it are different. The security model you’re describing is the same as someone entering their secret key in the “not…

A password manager that does not allow one to log in to the wrong site is still very useful. Also, just because you're entering a master secret in doesn't mean it's any easier to get it out. The user could simply be required to generate the master secret herself and back it up on her own.

Sounds basically like a key store/loader like this one: https://www.cryptomuseum.com/crypto/usa/kyk13/index.htm. I have a little experience with its successor. There’s a legit purpose for it but it’s a different animal then an HSM in my opinion.
Post reply on HN