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

21–30 of 57 posts

Re: FIDO Alliance

#21

Post by TacticalCoder »

What is really great with FIDO is that, if you're using a proper device the device also tells the user that he's authenticating to a site he previously registered on. So the user cannot be tricked into registering his key to, say, g00gle (with two zeroes) when he thinks he's actually authenticating with an already onboarded key.

A friend has got a U2F device (forgot its name) which has six buttons that serves to enter a PIN and the PIN to authenticate and the PIN to register are different ones.

Or the Ledger Nano S hardware wallet (and probably the X too) have a U2F app (so the "older" standard only atm) but there it's even better: the device not only tells you if you're registering the key for the first time or authenticating but it also displays the name of the site you're authenticating to.

This is one notch above many other authenticating methods: it doesn't just protect the server versus malicious users, it also protects honest users logging into malicious servers/websites.

Re: FIDO Alliance

#22

Post by db65edfc7996 »

drdaeman wrote: post #5
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.

The only real problem with passwords is that humans are extremely bad at those without an aid of a password manager (when they’re no longer words but turn into pre-shared tokens). There are more, of course, but not as important. So people invented OpenID and OAuth and stuff, but all those things are fundamentally flawed because users were no longer a source of their “own” identifies. Their identities became provided…

>The only real problem with passwords is that humans are extremely bad at those without an aid of a password manager (when they’re no longer words but turn into pre-shared tokens)

Human are also bad at not losing/breaking their magical security totem. I need to know that I can easily backup codes to any of these hardware tokens for if/when one is lost. Ultimate security be damned.

Re: FIDO Alliance

#23

Post by eikenberry »

drdaeman wrote: post #5
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.

The only real problem with passwords is that humans are extremely bad at those without an aid of a password manager (when they’re no longer words but turn into pre-shared tokens). There are more, of course, but not as important. So people invented OpenID and OAuth and stuff, but all those things are fundamentally flawed because users were no longer a source of their “own” identifies. Their identities became provided…

It is implicitly centralized if the user doesn't have a means to control the secret key themselves. The minimally need to be able to import new keys into a device to keep control. Otherwise whoever owns those keys is really the one in control, which is really what the higher FIDO levels are about (as they are targeting enterprise customers that want central control).

L1 (software based) obviously fits this requirement. I think L2 also can because while it is a physical key it could allow for the user to import their own secret. L3 takes that away as it must come from the manufacture with a key that cannot be accessed. Not 100% on any of this, but it's what I get from their level doc... https://fidoalliance.org/certification/authenticator-certifi...

Re: FIDO Alliance

#24

Post by TacticalCoder »

eikenberry wrote: post #19
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?

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.

Wait: what about these higher certification? Is there going to be some kind of "master key", controlled by the FIDO alliance (?), that would somehow sign the keys produced by "complying" company X or Y? Making it impossible to come with a software implementation allowing to users to backup their keys? Or are you saying that a software implementation would be totally doable but just wouldn't be officially certified?

Re: FIDO Alliance

#25

Post by magicalhippo »

eikenberry wrote: post #20
magicalhippo wrote: post #14

Earlier quoted context omitted.

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

> store it somewhere safe

That's what I meant. How exactly would one safely store this secret? How would you prevent an adversary from extracting the secret from the storage?

Re: FIDO Alliance

#26

Post by akira2501 »

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…

> just kind of suck at p/w management.

The risk/reward ratio doesn't justify it in their lives. It's also a pernicious ratio because there is almost no way to increase the "reward" portion, just decrease "risk."

In my experience, solutions balanced on this type of ratio always fail to solve the fundamental problem. Which is why we have to have commercials that tell people "medicare will _never_ call you. If anyone calls and says they're from medicare, hang up immediately!" So, I'm assuming we can now look forward to "no one will ever call and ask for information from your key, if they do, hang up!"

I also expect a similar outcome.

Re: FIDO Alliance

#27

Post by moduspol »

akira2501 wrote: post #26
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…

> just kind of suck at p/w management. The risk/reward ratio doesn't justify it in their lives. It's also a pernicious ratio because there is almost no way to increase the "reward" portion, just decrease "risk." In my experience, solutions balanced on this type of ratio always fail to solve the fundamental problem. Which is why we have to have commercials that tell people "medicare will _never_ call you. If anyone ca…

> The risk/reward ratio doesn't justify it in their lives. It's also a pernicious ratio because there is almost no way to increase the "reward" portion, just decrease "risk."

Eh, my non-tech savvy friends/relatives find themselves guessing at and then finally resetting their password surprisingly frequently. There's some room for "reward" there.

Re: FIDO Alliance

#28

Post by Zamicol »

FIDO does some dirty things:

>FIDO requires an attestation private key, which must be shared between a batch of at least 100,000 security keys. Using a DIY or cli app solution (application running on the host) will likely mean you'll be generating that private key yourself, this makes you identifiable across registrations.

>Some sites (Cloudflare) may reject the use of attestation keys which are not found on the Fido Alliance Metadata Service. This precludes the use of any DIY solution.

>https://fidoalliance.org/metadata/

>https://support.cloudflare.com/hc/en-us/articles/44068890480...

Taken from a previous Hacker News discussion: https://news.ycombinator.com/item?id=31294316#31295128

Re: FIDO Alliance

#29

Post by vanburen »

magicalhippo wrote: post #25
eikenberry wrote: post #20

Earlier quoted context omitted.

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.

> store it somewhere safe That's what I meant. How exactly would one safely store this secret? How would you prevent an adversary from extracting the secret from the storage?

Personally I would store it in a Keepass DB stored offline on a USB drive, in a safe location.

Re: FIDO Alliance

#30

Post by eikenberry »

magicalhippo wrote: post #25
eikenberry wrote: post #20

Earlier quoted context omitted.

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.

> store it somewhere safe That's what I meant. How exactly would one safely store this secret? How would you prevent an adversary from extracting the secret from the storage?

Various strategies that trade off security vs. convenience. Most secure is probably something simple like printing it out and putting that in a fire-proof safe. But there are lots of options. For the non-tech parents or some such, a nice pass-phrase would probably work well as the secret.
Post reply on HN