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

301–310 of 525 posts

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

#301

Post by danuker »

anthony_r wrote: post #96
eMGm4D0zgUAVXc7 wrote: post #91

Earlier quoted context omitted.

> It's very hard to make a privacy case against FIDO. With username and password, I have full control over my privacy in a very easy to understand fashion: If I randomly generate them I know I cannot be tracked (as long as I ensure my browser doesn't allow it by other means). With those keys I have a opaque piece of hardware which transfers an opaque set of data to each website I use and I have NO idea what data that…

> Which is rather likely, because why else would big tech companies push this if it didn't benefit them in some way? They switched to this internally a long time ago which basically eliminated phishing attacks against employees. There are security teams inside those megacorps that have a general objective of reducing the number of account takeovers, and non trivial resources to accomplish that. Not everything is a co…

> There are security teams inside those megacorps that have a general objective of reducing the number of account takeovers

Said security teams have at most zero incentive that the privacy of the policy subjects is preserved.

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

#302

Post by aaaaaaaaata »

daenz wrote: post #258

It would be nice for Amazon to commit as well. AWS has support for only a single Yubikey, which is mostly useless, unless you don't care about being locked out of your account if you lose that one key.

Yeah, they should be ashamed of themselves — forget losing it, what if it fails...?

It's bad practice to register just one hardware key, if your service has no side-doors.

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

#303

Post by xur17 »

aaaaaaaaata wrote: post #297
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...

Any input which (Trezor/Ledger) is least likely to be a honeypot?, and/or a good device?

What do you mean by a honeypot? Both are pretty well trusted devices, and users easily have tens of billions of dollars deposited on them. Given that, I feel pretty comfortable using them for 2fa.

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

#304

Post by mmis1000 »

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.

I think FIDO is not meant to be backup at first place. It's more a derived key exists to authenticate certain device safely without being stolen to authenticate other you aren't expected. Make it easily backupable actually defeats its whole purpose if it is intended to be used this way.

And for service that actually want it to be used as major key. I think they can just make the one authenticated able to authenticate another(and even decide whether this new device can auth yet another or not). (Like the way google use: popup on user phone, and ask if user would like to let the computer login.)

I think the one we actually need is a common protocol to authenticate new fido device from existing one. Although you can do it currently, every website have different flow to do it. And there is not currently a common way here. A common and machine understandable way to auth new device from existing one may ease the pain.

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

#305

Post by ChikkaChiChi »

Arnavion wrote: post #291
ChikkaChiChi wrote: post #283

Why aren't we doing more to validate the identity of the service we are trying to connect to? CAs don't allow me to establish my own personal web of trust. If I connect once to my bank in a method I deem safe, I should be able to store their credentials in an easy to validate way. That way if I fall for a phishing attack, the browser can CLEARLY indicate to me that I'm encountering a new entity, not one I have an est…

They closest thing to avoiding being phished by a different "secure" entity is that your password manager will refuse to autofill (*) your credentials. But it's true that this is far from sufficient - this kind of autofill is wonky and doesn't work with all pages, so users can get conditioned to working around it by manually copying and pasting from the password manager to the browser, which defeats the protection. M…

You're right, that's woefully insufficient. The authentication challenge should clearly (using color and text) whether or not the challenge is an established part of your trust network and the hardware token should be able to validate the authenticity of the challenge modal itself.

Users should be able to take an action they trust, while at the same time having the choice of that action taken away (or made more cumbersome) if they are about to get themselves into trouble.

There are people far smarter than me working on these problems, but I feel like they are so hyperfocused on state-security that they refuse to listen to anyone regarding actual usability.

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

#306

Post by eikenberry »

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.

Yes there are. FIDO specifies different authentication levels and level 1 allows access to the master keys (it allows for pure software implementations). I think this page gives a decent overview of the levels... https://fidoalliance.org/certification/authenticator-certifi...

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

#307

Post by jeroenhd »

sdfgdfgbsdfg wrote: post #279
jeroenhd wrote: post #5

I hope this cross device system will be cross platform, but I wouldn't be surprised if you could only choose between macOS/iOS, Chrome/Chrome, or Edge/Edge sync. Funnily enough, a system for signing web authentication requests from a mobile device is far from new: I've been using https://krypt.co/ for years (though it's on the long road of sunsetting right now) and I hope that will last long enough for the new cross…

It won't, at least not in the short term. For that to happen trusted platform modules would need an api to export a private key wrapped with a certificate signed by (none/one/all/a quorum) of members in the circle of trust and itself. This will need standardizing. Only apple has implemented it so far because it has total control of their ecosystem. I think for Windows and Chrome to work like this, they'll need to sta…

I think the first iteration of this system will definitely receive the synced key material in RAM.

It's possible that the TPM spec will be updated to allow for loading pre-encrypted data into the TPM store as a response to this. Alternatively, existing secure computing systems (SGX/TrustZone) can also be used to decrypt the synchronised key relatively securely.

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

#308

Post by lxgr »

mmis1000 wrote: post #304
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.

I think FIDO is not meant to be backup at first place. It's more a derived key exists to authenticate certain device safely without being stolen to authenticate other you aren't expected. Make it easily backupable actually defeats its whole purpose if it is intended to be used this way. And for service that actually want it to be used as major key. I think they can just make the one authenticated able to authenticate…

At least the WebAuthN standard seems to be moving in a different direction [1], which is also surprising to me.

In a nutshell, it will be possible for relying parties (i.e. websites) to detect multi-device/backup capable authenticators if required, but disabling multi-device functionality would require a very explicit opt-out, not an opt-in, on the relying party's side.

[1] https://github.com/w3c/webauthn/issues/1714

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

#309

Post by lxgr »

sheerun wrote: post #298
_vdpp wrote: post #280

Earlier quoted context omitted.

I think the whole point of HSMs is that you can’t back up (read: exfiltrate) the master secrets. Having said that, on certain Yubikeys you can store PGP keys on them, and put the same secret key on several different Yubis. If you’re relying on a hardware key it’s probably a good idea to have a backup key and make sure both are registered with whatever system you’re accessing. LastPass and GitHub at least support addi…

A backup key could have ability to reject original one, problem solved...

How would that work in practice? Key/certificate revocation is notoriously hard.

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

#310

Post by mjevans »

throwaway52022 wrote: post #199
zozbot234 wrote: post #188

Earlier quoted context omitted.

Software ("virtual") implementations are already possible in WebAuthn. It's up to the service whether to allow enrollment via a software authenticator; most services will want to allow this, seeing as it's still way more secure than ordinary username/password.

For web apps/services, the browser needs to be involved here too, right? (And maybe the OS?) How can I tell Chrome on my desktop to use my "software token" instead of Chrome looking for a hardware token over USB or finding it via NFC, so the remote service can ultimately interact with my (virtual) token? (I don't even want to think about how to tell Mobile Safari on my iPhone how to find my key) EDIT: My ideal setup,…

I do NOT want to use my phone. It cannot be considered to be a secure device given the 'network' baseband control chipset will never be owned by the phone's buyer and has full access to the device.
Post reply on HN