9 ms·

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

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.

jupp0r 4y ago
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.
drdaeman 4y ago
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 4y ago
  >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 4y ago
    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 4y ago
  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-certification-levels/ https://fidoalliance.org/certification/authenticator-certifi...
  - supertrope 4y ago
    That's the trade-off between security for the masses and savvy individuals having more control. A person can't get phished for their credentials if they can't access the private key. Journalists have emailed their GPG private key when learning how to use it. Even TOTP can be beat with fake webpages or a social engineer who asks for the code.
eulers_secret 4y ago
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 4y ago
  > 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 4y ago
    It pretty much is as far as I know. There are even open source hardware key specs.
  - vanburen 4y ago
    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 4y ago
      > 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?
deleted 4y ago
[deleted]
eikenberry 4y ago
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.
Rafert 4y ago
You don't need those either, perhaps https://github.com/herrjemand/awesome-webauthn https://github.com/herrjemand/awesome-webauthn is more to your liking than the website of a standards organization.
tialaramex 4y ago
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.

jupp0r 4y ago

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.

drdaeman 4y ago

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 4y ago
>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 4y ago
  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 4y ago
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-certification-levels/ https://fidoalliance.org/certification/authenticator-certifi...
- supertrope 4y ago
  That's the trade-off between security for the masses and savvy individuals having more control. A person can't get phished for their credentials if they can't access the private key. Journalists have emailed their GPG private key when learning how to use it. Even TOTP can be beat with fake webpages or a social engineer who asks for the code.

eulers_secret 4y ago

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 4y ago
> 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 4y ago
  It pretty much is as far as I know. There are even open source hardware key specs.
- vanburen 4y ago
  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 4y ago
    > 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?

deleted 4y ago

[deleted]

eikenberry 4y ago

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.

Rafert 4y ago

You don't need those either, perhaps https://github.com/herrjemand/awesome-webauthn https://github.com/herrjemand/awesome-webauthn is more to your liking than the website of a standards organization.

tialaramex 4y ago

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.