Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FIDO Alliance

fidoalliance.org

Post reply on HN
Print view View original

11–20 of 57 posts

Re: FIDO Alliance

#11

Post by cowtools »

yakak wrote: post #9
yobbo wrote: post #4

Seems it's like ssh keys, but fiddled automatically in the browser. A password unlocks the local keys. This means keys need to be transported between devices. Which means even tighter coupling to google and microsoft accounts.

> This means keys need to be transported between devices Pure keys are on tokens that support Bluetooth/NFC/USB to talk to whatever devices you want. One can use a built in key on a device with a security enclave which means using one device to auth addition of another, but you might do that with alerts to authorize, etc. Anyone who doesn't have a powned problem is using something like TOTP auth codes which has all o…

You couldn't just emulate the secure enclave?

Re: FIDO Alliance

#12

Post by vanburen »

car_analogy wrote: post #8
eulers_secret wrote: post #7

Earlier quoted context omitted.

I've had so many of my non-tech relatives get hacked. Folks who don't live/breath/shit tech just kind of suck at p/w management. This is a huge improvement for them. BUT, I absolutely think we should continue to demand the right to interact with services on our own terms: Even accepting the compromise of "less security" (debatable if you know what you're doing). I think the only way forward is a Free/Libre implementa…

> implementation of FIDO2 that is NOT linked to any specific device and can be modified - along with direct access to the keys. Those are the users property and should not be held hostage by hostile designs. Users should have the right to move their keys, without justification, and use whatever manager they want Is this not possible with current designs?

At least as I understand it, in implementations like yubikey the FIDO2 secret is baked-in to the yubikey for security, which is good as it shouldn't be possible to remove the private key.

However the main issue I have is that the user cannot import their own secret into the yubikey, so you cannot choose to use your own secret vs the factory generated one, or choose to have multiple yubikeys using the same secret, which would be useful as you wouldnt need to enrol multiple secrets with each service.

Re: FIDO Alliance

#13

Post by [deleted] »

akersten wrote: post #2

Hmm, seminars and "certified professional" exams. I don't recall needing those in order to understand or implement username/password auth. I keep hearing this is simpler and more secure, but I really doubt explaining this to my aging parents is going to be a fun afternoon. Can we just leave well enough alone? Was never a fan of centralizing my identity in the first place.

[deleted]

Re: FIDO Alliance

#14

Post by magicalhippo »

vanburen wrote: post #12
car_analogy wrote: post #8

Earlier quoted context omitted.

> implementation of FIDO2 that is NOT linked to any specific device and can be modified - along with direct access to the keys. Those are the users property and should not be held hostage by hostile designs. Users should have the right to move their keys, without justification, and use whatever manager they want Is this not possible with current designs?

At least as I understand it, in implementations like yubikey the FIDO2 secret is baked-in to the yubikey for security, which is good as it shouldn't be possible to remove the private key. However the main issue I have is that the user cannot import their own secret into the yubikey, so you cannot choose to use your own secret vs the factory generated one, or choose to have multiple yubikeys using the same secret, whi…

> However the main issue I have is that the user cannot import their own secret into the yubikey

Where would you get this secret from in a secure way? How would you prevent a nefarious actor from exporting it and importing it into their own yubikey or similar?

Re: FIDO Alliance

#15

Post by yakak »

cowtools wrote: post #11
yakak wrote: post #9

Earlier quoted context omitted.

> This means keys need to be transported between devices Pure keys are on tokens that support Bluetooth/NFC/USB to talk to whatever devices you want. One can use a built in key on a device with a security enclave which means using one device to auth addition of another, but you might do that with alerts to authorize, etc. Anyone who doesn't have a powned problem is using something like TOTP auth codes which has all o…

You couldn't just emulate the secure enclave?

You can, just like you can store your TOTP key in your password manager to have the security of 1FA again.

A site that doesn't want you to could try to use attestation certificates to force you to use a real vendor's keys which should never be extractable.

Re: FIDO Alliance

#16

Post by yaaligator »

The problem with the FIDO "alliance" is who runs it, which is corporate America and megabanks if you check the site. They are basically trying to be the arbiters of online identity, gaining more power than they already have. Many of these companies are also in surveillance tech. That it may or may not be more secure than existing practices is merely a side effect. Don't be fooled by the term "alliance" because you are not part of the club.

Re: FIDO Alliance

#17

Post by jtcasper »

eulers_secret wrote: post #7
akersten wrote: post #2

Hmm, seminars and "certified professional" exams. I don't recall needing those in order to understand or implement username/password auth. I keep hearing this is simpler and more secure, but I really doubt explaining this to my aging parents is going to be a fun afternoon. Can we just leave well enough alone? Was never a fan of centralizing my identity in the first place.

I've had so many of my non-tech relatives get hacked. Folks who don't live/breath/shit tech just kind of suck at p/w management. This is a huge improvement for them. BUT, I absolutely think we should continue to demand the right to interact with services on our own terms: Even accepting the compromise of "less security" (debatable if you know what you're doing). I think the only way forward is a Free/Libre implementa…

My Solokey is hackable and firmware available under Apache/MIT (https://github.com/solokeys/solo1).

Unfortunately the easiest way to "export" is likely to rely on the RP, as if they effectively use the sign_counter they may flag such a key as cloned. They should ideally just let you register multiple (and that's an RFC 'SHOULD').

Not a shill by the way, just a happy solokey owner.

Re: FIDO Alliance

#18

Post by eikenberry »

akersten wrote: post #2

Hmm, seminars and "certified professional" exams. I don't recall needing those in order to understand or implement username/password auth. I keep hearing this is simpler and more secure, but I really doubt explaining this to my aging parents is going to be a fun afternoon. Can we just leave well enough alone? Was never a fan of centralizing my identity in the first place.

As long as it sticks with FIDO2 Authenticator L1, it doesn't require centralization of the auth information like levels L2 and L3 do. L1 is what you use if you want control. L2 and L3 are for companies who want tighter, centralized control. Like a FIDO key tied to your Okta account. Though I've yet to see the Levels discussed much nor have I seen any L1 software implementations used in the wild. Everyone seems focused on FIDO L2 and higher, presumably with a focus on getting enterprise adoption first as enterprises do want a central authority.

Re: FIDO Alliance

#19

Post by eikenberry »

car_analogy wrote: post #8
eulers_secret wrote: post #7

Earlier quoted context omitted.

I've had so many of my non-tech relatives get hacked. Folks who don't live/breath/shit tech just kind of suck at p/w management. This is a huge improvement for them. BUT, I absolutely think we should continue to demand the right to interact with services on our own terms: Even accepting the compromise of "less security" (debatable if you know what you're doing). I think the only way forward is a Free/Libre implementa…

> implementation of FIDO2 that is NOT linked to any specific device and can be modified - along with direct access to the keys. Those are the users property and should not be held hostage by hostile designs. Users should have the right to move their keys, without justification, and use whatever manager they want Is this not possible with current designs?

It is possible under FIDO L1 certification, but Yubikey and most other players are focusing on L2 and L3 certification as that will be what enterprise customers want.

Re: FIDO Alliance

#20

Post by eikenberry »

magicalhippo wrote: post #14
vanburen wrote: post #12

Earlier quoted context omitted.

At least as I understand it, in implementations like yubikey the FIDO2 secret is baked-in to the yubikey for security, which is good as it shouldn't be possible to remove the private key. However the main issue I have is that the user cannot import their own secret into the yubikey, so you cannot choose to use your own secret vs the factory generated one, or choose to have multiple yubikeys using the same secret, whi…

> However the main issue I have is that the user cannot import their own secret into the yubikey Where would you get this secret from in a secure way? How would you prevent a nefarious actor from exporting it and importing it into their own yubikey or similar?

Secrets are easy to securely generate and it would allow importing, not exporting. If you allow importing then the user can generate the secret, store it somewhere safe and import it into the device. Then if they lose that device they can just write the saved secret to a new key.
Post reply on HN