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

61–70 of 525 posts

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

#61

Post by eMGm4D0zgUAVXc7 »

vngzs wrote: post #38
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…

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 mean I have to move N backup keys out of their drawer to the workstation and register each of them on the account?

And how to even create a backup and keep it in sync?

With backup disks, it is a matter of shutting down the machine, removing one disk from the RAID1, and you have a backup (the removed disk is the backup). Or doing "dd if=..." if you don't use raid.

Is something as simple possible with those fancy crypto toys? Or is some arcane magic required to copy them?

Is this perhaps all as usual: An attempt to get more control and tracking of users, disguised as "security"?

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

#62

Post by 0daystock »

bedast wrote: post #55

The weakest link in security is always going to be humans. Account compromise is is more often a human problem than a technological one (spamming requests, password reuse, simple passwords, (spear) phishing, direct social engineering, etc). If I'm understanding correctly, they're aiming to reduce multi-factor auth back down to a single factor that's "easier" than passwords. Easier to use. Easier to social engineer a…

> If I'm understanding correctly, they're aiming to reduce multi-factor auth back down to a single factor that's "easier" than passwords.

It isn't only easier, it's significantly more secure. FIDO/U2F is basically immune to phishing, because there's no one-time code to type and steal; there's a cryptographically backed signing assertion guaranteeing the person with physical possession of the token is in control. This is so airtight (because almost all account compromise is done remotely, not through physical in-person attacks) that I would even be personally comfortable disclosing my password for accounts secured by FIDO/U2F.

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

#63

Post by throwaway52022 »

vngzs wrote: post #38
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…

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 spend a bunch of time when I visit to find that key and add it to all of my new accounts and hope I got everything - I want to make a backup of my current key right before I visit and when I visit, I just put the new backup key in the desk drawer and take the old one home with me.

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

#64

Post by CyberRage »

hansel_der wrote: post #57
CyberRage wrote: post #53

Earlier quoted context omitted.

Oh gosh... your raw bio-metrics are never stored anywhere... The signal from the sensor is used as a "seed" to generate key using robust cryptography Different sensors will output different "data" based on the sensor type.

> Oh gosh... your raw bio-metrics are never stored anywhere... right, who would do that... i mean for what purpose...

I mean you don't have to give it away if you think Google is storing databases of fingerprints for the lizard masters to track you down.

FIDO simply wants to make authentication stronger, you can use hardware keys that have a key burnt into them which is unique and much harder to brute-force than passwords.

Again according to how biometrics are described in whitepapers\industry, we extract features from the fingerprint\face sometimes very little compared to the actual biometric and use it to derive a key. that key cannot be reversed to get the original features and different algorithms use different features.

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

#65

Post by michaelt »

vngzs wrote: post #38
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…

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.

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

#67

Post by 0daystock »

Andrew_nenakhov wrote: post #43

Played with the Yubikeys a couple of days ago. Rather nice thingies that are very easy to lose somewhere.

It's reasonably safe to leave them connected to the devices you regularly authenticate from, unless your threat model includes an adversary willing to use physical attacks.

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

#68

Post by imoverclocked »

CyberRage wrote: post #53
alberth wrote: post #47

Earlier quoted context omitted.

> Bio-metrics are just convenient because they are unique and hard\impossible to replicate. But if your biometric is able to be faked, you can't change it like you can change a typical text based password. There's no "reset your password" equivalent for biometrics.

Oh gosh... your raw bio-metrics are never stored anywhere... The signal from the sensor is used as a "seed" to generate key using robust cryptography Different sensors will output different "data" based on the sensor type.

> your raw bio-metrics are never stored anywhere...

Unless you have a drivers license in California where they require inked versions of your biometrics.

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

#69

Post by vlan0 »

bedast wrote: post #55

The weakest link in security is always going to be humans. Account compromise is is more often a human problem than a technological one (spamming requests, password reuse, simple passwords, (spear) phishing, direct social engineering, etc). If I'm understanding correctly, they're aiming to reduce multi-factor auth back down to a single factor that's "easier" than passwords. Easier to use. Easier to social engineer a…

>"Passwordless" just means that prompt goes to an app where a user unlocks their device to approve the login.

Setup a yubikey with an attested cert/pub key. Require a pin to use said yubikey.Requiring attestation will prove that private key was generated on the device, and will only live on that yubikey. That's your best bet.

It also satisfies the multi-factor needs. The something you have is the yuibkey. The something you know is the PIN.

Post reply on HN