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

371–380 of 525 posts

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

#371

Post by 0daystock »

dane-pgp wrote: post #229
0daystock wrote: post #20

Earlier quoted context omitted.

My vision of future authentication (shared by colleagues in security) is based in strong hardware credentials and additional layer-7 context about identity, device and location. Basically, more identification of you and your browser using cryptographically-guaranteed and immutable events. It is actually the deprecation of passwords altogether and generally moving the trust boundary away from the control of the user e…

> additional layer-7 context about identity, ... more identification of you Mass surveillance. You can just say mass surveillance.

Every technology is a double-edged sword. Like firearms, security controls can be used to guarantee peace and freedom or wage war and distress. The responsibility is with the administrator of that tool, not the tool itself.

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

#373

Post by amf12 »

snarf21 wrote: post #256
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 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.

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

#375

Post by _vdpp »

adrian_b wrote: post #349
_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…

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 “notes” app in a phone, leaving it in Airplane mode with FDE and wipe after a certain number of incorrect PIN entries. You can call that a “HSM”, but it’s not what I’d consider one.

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

#376

Post by tialaramex »

ChikkaChiChi wrote: post #326
blibble wrote: post #323

Earlier quoted context omitted.

U2F/FIDO2 are immune to this problem as the magic exchange requires the origin hostname to decrypt/verify the remotely stored blob wrong origin? can't work at all, ever

Thanks you for your response. I'm going to read up more. I wasn't aware this was a feature.

Specifically what's going on here in the cheapest FIDO devices is roughly this:

On every site where you enroll, random private keys are generated - this ensures you can't be tracked by the keys, your Facebook login and your GitHub login with WebAuthn are not related, so although if both accounts are named "ChikkaChiChi" there are no prizes for guessing it's the same person, WebAuthn does not help prove this.

A private key used to prove who you are to say example.com is not stored on the device, instead, it's actually encrypted using a symmetric key that is really your device's sole "identity" the thing that makes it different from the millions of others, and with a unique "Relying Party" ID or RPID which for WebAuthn is basically (SHA256 of) the DNS name using AEAD encryption mode, and then, sent to example.com during your enrolment, along with the associated public key and other data.

They can't decrypt it, in fact, they aren't formally told it's encrypted at all, they're just given this huge ID number for your enrolment, and from expensive devices (say, an iPhone) it might not be encrypted at all, it might just really be a huge randomly chosen ID number. Who knows? Not them. But even if they were 100% sure it was encrypted too bad, the only decryption key is baked inside your authenticator which they don't have.

What they do have is the public key, which means when you can prove you know that private key (by your device signing a message with it) you must be you. This "I'm (still) me" feature is deliberately all that cheap Security Keys do, out of the box, it's precisely enough to solve the authentication problem, with the minimum cost to privacy.

Now, when it's time to log in to example.com, they send back that huge ID. Your browser says OK, any Security Keys that are plugged in, I just got this enrolment ID, from example.com, who can use that to authenticate ? Each authenticator looks at the ID, and tries to decrypt it, knowing their symmetric key and the fact it's for example.com. AEAD mode means the result is either "OK" and the Private Key, which they can then use to sign the "I'm (still) me" proof for WebAuthn and sign you in, or "Bzzt wrong" with no further details and that authenticator tells the browser it didn't match so it must be some other authenticator.

This means, if you're actually at example.org instead of example.com the AEAD decryption would fail and your authenticator doesn't even know why this didn't work, as far as it knows, maybe you forgot to plug in the right authenticator? You not only don't send valid credentials for example.com to the wrong site, your devices don't even know what the valid credentials are because they couldn't decrypt the message unless it's the correct site.

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

#378

Post by kozd »

danuker wrote: post #272
avianlyric wrote: post #147

Earlier quoted context omitted.

> Without making any explicit argument for it, what I see coming out of Fido and U2F are really changing the importance of the long-standing "something you have, something you know..." mindset around security. That prior mode was not helping us design system that take human capabilities of the user into account. Don’t think that’s quite true. It’s continuation of the old “something you know”, “something you have” and…

> you're password Pardon my pedantry, but you should only use the apostrophe (') to show you are joining two words. In this case, the words are "you" and "are", merging into "you're". "you are password" is what I read.

Are you a bot?

> "but you should only use the apostrophe (') to show you are joining two words. In this case, the words are "you" and "are", merging into "you're"."

Is obvious, unnecessary and condescending.

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

#379

Post by zozbot234 »

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

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.

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

#380

Post by tialaramex »

rad88 wrote: post #243
fmakunbound wrote: post #187

Reading through the threads here: If the HN can't articulate FIDO and differences between it and the now decades old password model to each other, I think regular jack-offs are going to have trouble. People have the mental model that their secret is stored in their gray matter/post-it note/password manager, and now you're telling them it's in their phone, and somewhat related to the phone's security model, or maybe a…

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 now it's secure.

Post reply on HN