[HN Gopher] FIDO Alliance
___________________________________________________________________
FIDO Alliance
Author : gjvc
Score : 135 points
Date : 2022-06-06 18:21 UTC (4 hours ago)
(HTM) web link (fidoalliance.org)
(TXT) w3m dump (fidoalliance.org)
| jefurii wrote:
| I clicked on this hoping it was about FidoNet
| (https://en.wikipedia.org/wiki/FidoNet).
| neoCrimeLabs wrote:
| My first thought was "Is FIDOnet still relevant after all these
| decades?" then remembered FIDO U2F
| TacticalCoder wrote:
| 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.
| dyml wrote:
| Yes, fido2 defeats allot of the attack vectors for phishing
| attacks and is great.
|
| While physical devices probably will mostly be used for
| enterprises and us nerds, "platform Authenticators (e.g
| passkeys) offer much of the same security without the physical
| device
| yobbo wrote:
| 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.
| yakak wrote:
| > 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 of the downside of Fido and
| none of the convenience.
| cowtools wrote:
| You couldn't just emulate the secure enclave?
| yakak wrote:
| 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.
| throwaway92394 wrote:
| Or apple's iCloud (see their passkey thing also currently on
| the front page)
|
| EDIT: Yes you don't need to use a syncing service. But it will
| be important for it to be portable between syncing services, as
| that is what most consumers will be using.
| yaaligator wrote:
| 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.
| supertrope wrote:
| They're just trying to replace the current system of password
| reset calls, SMS two factor, credential stuffing following
| password database breaches, and general sense of insecurity
| online.
| Zamicol wrote:
| 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
| dyml wrote:
| Please note that verifying Metadata is optional for a RP (site
| owner) and very few sites need it. Without metadata information
| the privacy is improved.
|
| Disclosure: We built an open source library and an API that
| makes it easy to add WebAuthn/Fido to your existing web app.
| It's available at for those who want to take a look.
| https://www.passwordless.dev/
|
| There is also a more configurable demo page for the library
| where you can turn metadata on/off (the api is default off)
| tialaramex wrote:
| In Firefox you can, and I do, tell the browser to refuse
| Attestation. There's a prompt during the enrolment process.
|
| There's no reason why you should provide Attestation for the
| Web generally. It could make sense (though I'd argue it does
| not) for some specialised applications but generally it's
| probably a waste of your time (collating the necessary data to
| make it work) and your users time (now some stuff they want
| doesn't work and needs explicit authorisation).
| psanford wrote:
| Chrome also allows you to say no to Attestation requests.
|
| The only place I've seen a 'legitimate' use for requesting an
| attestation cert is to ensure that only specialized FIPS
| hardware is allowed to be registered when that is a business
| obligation.
| psanford wrote:
| Most open source tools I've seen that implement FIDO use a
| shared Attestation cert[0].
|
| [0]:
| https://github.com/github/SoftU2F/blob/master/SelfSignedCert...
| jaredhanson wrote:
| Attestation is an option in the FIDO ecosystem, and it is up to
| each website whether or not attestation is needed. Attestation
| is often required in enterprise settings. While consumer
| adoption of WebAuthn is incredibly low, the introduction of
| passkeys and multi-device credentials looks poised to change
| that.
|
| For consumer scenarios, attestation is often not a requirement.
| In that case, FIDO offers the "none" and "self" attestation
| modes. None conveys no attestation. Self attestation involves a
| per-website key pair. Either of these modes are privacy and DIY
| friendly.
| tjoff wrote:
| Well, cloudfare seems to be doing it to combat bots.
|
| We actually managed to invent something even worse than
| passwords. Incredible.
| akersten wrote:
| 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.
| eulers_secret wrote:
| 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 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. Even
| a fully-software one.
| car_analogy wrote:
| > 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?
| Freak_NL wrote:
| It pretty much is as far as I know. There are even open
| source hardware key specs.
| vanburen wrote:
| 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.
| magicalhippo wrote:
| > 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?
| eikenberry wrote:
| 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.
| magicalhippo wrote:
| > 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?
| vanburen wrote:
| Personally I would store it in a Keepass DB stored
| offline on a USB drive, in a safe location.
| eikenberry wrote:
| 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.
| magicalhippo wrote:
| How do you get this pass-phrase from paper onto the
| yubikey without an adversary getting hold of it?
|
| I'm not trying to be pedantic here, I'm just failing to
| see how this can be realistically implemented without
| significantly lowing the overall security. But this is
| also not my domain, so I'd like to learn.
| eikenberry wrote:
| 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.
| TacticalCoder wrote:
| 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?
| jtcasper wrote:
| 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.
| akira2501 wrote:
| > 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.
| moduspol wrote:
| > 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.
| ChadNauseam wrote:
| > 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!"
|
| There's usually no way to take your key off your device, so
| don't worry about that :P
| tialaramex wrote:
| I guess it's possible that particularly vulnerable people
| might be persuaded to physically _send_ the actual device
| to bad guys. I 'd like to hope that existing advice to
| such people warns them not to send stuff to bad guys, we
| don't want them sending their credit cards, house keys,
| etc. to bad guys either.
| jupp0r wrote:
| It's simple for users. No need to remember passwords anymore,
| no typing 6 digits numbers from your phone that you need to
| search in your house before tokens expire.
|
| This comes with (some) additional complexity for implementing
| more complex auth flows for developers.
|
| If you think that passwords are working "well enough" today you
| are clearly not educated on how most users (mis)use them. If
| you built a site and tried out the passwords people send to you
| on the logins for providers of the email addresses they send to
| you, there'd be a large fraction of people reusing their email
| account password for your service, allowing you to access their
| email.
| tialaramex wrote:
| What's there to explain? We're presumably not teaching your
| parents to actually _implement_ this for a web site (although I
| did it in a weekend once to learn) just to use it. Do your
| ageing parents still have car keys? House keys at least? The
| physical Security Keys are probably easiest to grok for older
| people, because of that familiarity.
| drdaeman wrote:
| 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 by third parties - and this is notoriously bad.
|
| WebAuthn (and FIDO stuff) is not centralized, on the contrary -
| users still own their credentials and are sources of their
| identities (though there are optional attestations). It doesn't
| require cryptography knowledge to use it, but it does to
| implement it - thus the certification (though anyone can surely
| do it without certifying for anything).
| db65edfc7996 wrote:
| >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.
| postalrat wrote:
| Whats wrong with authenticating multiple tokens and backing
| up the physical tokens?
|
| I'd rather know that each token is unique and not wonder
| how many copies of the token exist.
| eikenberry wrote:
| 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...
| Rafert wrote:
| You don't need those either, perhaps
| https://github.com/herrjemand/awesome-webauthn is more to your
| liking than the website of a standards organization.
| eikenberry wrote:
| 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.
| [deleted]
| woliveirajr wrote:
| Apple, Microsoft and Google together to improve how you login to
| sites without password. And they will store your "secret" so that
| you don't need to type it. And you'll be able to recover from any
| device that is already authenticated.
|
| At the same time, every week we see a "Tell HN: how I lost all
| access to my email/site/account because of {reason}", where
| {reason} is some stupid thing that the AI flagged.
|
| Seems that we'll able to lose access to the whole digital world
| if just one company makes some mistake. Yes, they will.
| drexlspivey wrote:
| Unlike username/password you can register as many FIDO devices
| as you like in each service so if you lose one (because Apple
| disabled your Apple ID or whatever) you can still login.
___________________________________________________________________
(page generated 2022-06-06 23:02 UTC)