33 ms·

The argument that passwords are acceptable as long as everyone practices good "hygiene" strikes me as having many parallels with the argument that C code is mem

The argument that passwords are acceptable as long as everyone practices good "hygiene" strikes me as having many parallels with the argument that C code is memory safe as long as it is written properly. I'd rather just have memory safety built in to the language I'm using—I'm not sure exactly what the equivalent is for passwords, but I don't think I would oppose it.

creshal 3y ago
> I'd rather just have memory safety built in to the language I'm using—I'm not sure exactly what the equivalent is for passwords, but I don't think I would oppose it. It's a hard problem. I don't think passkeys really are the solution long term, they just sweep the problem under a corporate rug and ignore that people will still use them inappropriately.
- rjzzleep 3y ago
  Not really, to some extent some amount of collateral damage is necessary for a free and open society. I don't want to live in a nanny state that decides everything for me. But somehow the same people arguing for ultimate freedom and OSS are also arguing for centralization of passwords into corporate controlled infrastructure. I'm somewhat at a loss on how to argue on these issues. You want to hand over control over your key infrastructure to big tech and you want the average population to do that as well? Go ahead. Most people on iPhones already use sign in with Apple with apples 2FA system anyway it won't matter to them. But why encroach on me and force me to use it to protect me from myself?
  - ValleZ 3y ago
    Because users who lost account because of lack of 2FA usually require attention and support resources. It’s easier to require more security than to figure out if this is a legitimate user who is trying to get access.
  - madeofpalk 3y ago
    What part of Passkeys is "centralization of passwords into corporate controlled infrastructure"? "Big Tech" does not control Passkeys beyond the work on the underlying WebAuthn spec https://www.w3.org/TR/webauthn-2/ https://www.w3.org/TR/webauthn-2/, and that they develop implementations of that spec.
  - 5e92cb50239222b 3y ago
    You can always use a FIDO2.1 key as a passkey, they're not tied to the big tech. I don't even have a smartphone and have been using them on the couple of sites that support passkeys just fine. We will also have at least one open software implementation when this gets merged: https://github.com/keepassxreboot/keepassxc/pull/8825 https://github.com/keepassxreboot/keepassxc/pull/8825 There are braindead implementations like PayPal's: https://www.paypal.com/us/cshelp/article/what-are-paypal-passkeys-help997 https://www.paypal.com/us/cshelp/article/what-are-paypal-pas... that force you to use Android or iOS, but it's nothing new, they manage to fuck up everything they touch (for example, U2F 2FA only supports registering one hardware key and it has been that way for years).
- cassianoleal 3y ago
  > they just sweep the problem under a corporate rug and ignore that people will still use them inappropriately. Can you expand on these 2 points? I'm still trying to wrap my head around passkeys and these are some of the arguments I see around but never quite explained.
  - michaelt 3y ago
    From a certain perspective, passkeys are a lot like using "Sign in with Google/Apple/Microsoft account" Because if this passkey stuff takes off with normal people, 98% of passkeys will be stored in cloud accounts with those providers. The weakest link in the security chain is the procedure for when the user forgets their password / loses their phone / gets a rootkit / gets phished / has their e-mail compromised. You can transfer that problem from your site to a cloud provider and hope they do a good job - but the problem doesn't go away.
    - cassianoleal 3y ago
      > 98% of passkeys will be stored in cloud accounts with those providers. They will also (and primarily) be stored in the individual devices, and don't need cloud access to the providers in order to be used. In this sense, it solves one of the main issues with third-party sign-in, i.e. that if the provider decides to lock your account, you get locked out of any linked services. > You can transfer that problem from your site to a cloud provider With passkeys? How so? Are passkeys not just cryptographic key pairs? If your service associates a certain account to a certain public key, there's nothing an external cloud provider can do to solve the issue you describe. It's possible I've missed something, like I said before I'm still wrapping my head around the whole thing.
      - michaelt 3y ago
        > If your service associates a certain account to a certain public key, there's nothing an external cloud provider can do to solve the issue you describe. Without passkeys, if one of my users lost their "second factor" (e.g. lost phone) I had to provide a flow for them to get into their account despite that, while remaining secure. With passkeys, users can restore their "second factor" from a cloud backup, so long as they can get access to that cloud backup. Hence, my lost-second-factor flow is outsourced to the user's cloud provider.

creshal 3y ago

> I'd rather just have memory safety built in to the language I'm using—I'm not sure exactly what the equivalent is for passwords, but I don't think I would oppose it. It's a hard problem. I don't think passkeys really are the solution long term, they just sweep the problem under a corporate rug and ignore that people will still use them inappropriately.

rjzzleep 3y ago
Not really, to some extent some amount of collateral damage is necessary for a free and open society. I don't want to live in a nanny state that decides everything for me. But somehow the same people arguing for ultimate freedom and OSS are also arguing for centralization of passwords into corporate controlled infrastructure. I'm somewhat at a loss on how to argue on these issues. You want to hand over control over your key infrastructure to big tech and you want the average population to do that as well? Go ahead. Most people on iPhones already use sign in with Apple with apples 2FA system anyway it won't matter to them. But why encroach on me and force me to use it to protect me from myself?
- ValleZ 3y ago
  Because users who lost account because of lack of 2FA usually require attention and support resources. It’s easier to require more security than to figure out if this is a legitimate user who is trying to get access.
- madeofpalk 3y ago
  What part of Passkeys is "centralization of passwords into corporate controlled infrastructure"? "Big Tech" does not control Passkeys beyond the work on the underlying WebAuthn spec https://www.w3.org/TR/webauthn-2/ https://www.w3.org/TR/webauthn-2/, and that they develop implementations of that spec.
- 5e92cb50239222b 3y ago
  You can always use a FIDO2.1 key as a passkey, they're not tied to the big tech. I don't even have a smartphone and have been using them on the couple of sites that support passkeys just fine. We will also have at least one open software implementation when this gets merged: https://github.com/keepassxreboot/keepassxc/pull/8825 https://github.com/keepassxreboot/keepassxc/pull/8825 There are braindead implementations like PayPal's: https://www.paypal.com/us/cshelp/article/what-are-paypal-passkeys-help997 https://www.paypal.com/us/cshelp/article/what-are-paypal-pas... that force you to use Android or iOS, but it's nothing new, they manage to fuck up everything they touch (for example, U2F 2FA only supports registering one hardware key and it has been that way for years).
cassianoleal 3y ago
> they just sweep the problem under a corporate rug and ignore that people will still use them inappropriately. Can you expand on these 2 points? I'm still trying to wrap my head around passkeys and these are some of the arguments I see around but never quite explained.
- michaelt 3y ago
  From a certain perspective, passkeys are a lot like using "Sign in with Google/Apple/Microsoft account" Because if this passkey stuff takes off with normal people, 98% of passkeys will be stored in cloud accounts with those providers. The weakest link in the security chain is the procedure for when the user forgets their password / loses their phone / gets a rootkit / gets phished / has their e-mail compromised. You can transfer that problem from your site to a cloud provider and hope they do a good job - but the problem doesn't go away.
  - cassianoleal 3y ago
    > 98% of passkeys will be stored in cloud accounts with those providers. They will also (and primarily) be stored in the individual devices, and don't need cloud access to the providers in order to be used. In this sense, it solves one of the main issues with third-party sign-in, i.e. that if the provider decides to lock your account, you get locked out of any linked services. > You can transfer that problem from your site to a cloud provider With passkeys? How so? Are passkeys not just cryptographic key pairs? If your service associates a certain account to a certain public key, there's nothing an external cloud provider can do to solve the issue you describe. It's possible I've missed something, like I said before I'm still wrapping my head around the whole thing.
    - michaelt 3y ago
      > If your service associates a certain account to a certain public key, there's nothing an external cloud provider can do to solve the issue you describe. Without passkeys, if one of my users lost their "second factor" (e.g. lost phone) I had to provide a flow for them to get into their account despite that, while remaining secure. With passkeys, users can restore their "second factor" from a cloud backup, so long as they can get access to that cloud backup. Hence, my lost-second-factor flow is outsourced to the user's cloud provider.