3 ms·

WebAuthn is "too complex" the way a catalytic convert is "too complex." If you don't know what it's for, it certainly seems like you can remove it with no downs

by md_ 5y ago

WebAuthn is "too complex" the way a catalytic convert is "too complex." If you don't know what it's for, it certainly seems like you can remove it with no downsides. ;) > Because it was in reply to my earlier comment saying this is not SSO. The person you were replying to was also not talking about SSO, which makes me think you don't understand that (valid, and fundamental) criticism of your proposal. :-/ > Webauthn is too complex. Which functionality would you remove, and what tradeoffs does that get you? > Passwords are bad. Hashes are dumped from databases and cracked. Surely it's easier for an IdP to use scrypt with some meaningful salt than to implement this fully novel and unsupported scheme. > Passwords are stuffed, etc. These seem like problems that affect password reuse. According to your design, users should just know better than to reuse keys, so...why not just know better than to reuse passwords? > There is no CA signing TLS certs, etc. So why not use self-signed X509 client certs instead? This is actually a thing browsers actually support. > The web service and its users are in full control of the process and they are using open-source software. This is a category error. We were discussing a protocol. If you think your specific implementation of that protocol is better than all the open source implementations of FIDO+WebAuthn, X509 client certs, PAKE, etc...well, you're probably wrong. :) > One goal I have is user anonymity. You have not explained how your system is more anonymous than the existing, well-defined, standards-compliant alternatives. Edit: Just to be clear about the tone of my feedback: my intention is to help you understand the context in which you are making your proposal and, ideally, understand the design tradeoffs existing systems have made. I know it's easy to become attached to an idea and take criticism like a personal attack. I hope you can take this constructively.

dcow 5y ago
Your tone is overly dismissive. If you want to be constructive then have a constructive conversation and not a dismissive knee jerk reaction. Your comment reads like “I haven’t read a standard for this or bothered to really take a look and it’s new therefore it’s fundamentally bad and insecure and not worth my time”. This repo is simply proposing using signed timestamps for auth. It would be nice to keep the discussion on that topic and it’s merits. Personally I think webauthn is not too complex and just needs to not be locked up in browser land so we can have a real softkey impl so we probably actually agree on our general outlook. You’re just kind a being a security diva about the whole thing and it’s not really fair to the author.
- md_ 5y ago
  Which part was knee jerk? I read everything on the (minimal) webpage. It doesn’t explain anything of substance, nor does it anticipate the (obvious) issues other commenters here noted. It’s like the author just proposed to remove everything they didn’t understand from Webauthn and was left with this. Honestly, this discussion isn’t worth the time. As for software webauthn keys: - What do you mean “locked up in browser land?” You can use FIDO elsewhere (e.g. ssh https://ubuntu.com/blog/enhanced-ssh-and-fido-authentication-in-ubuntu-20-04-lts https://ubuntu.com/blog/enhanced-ssh-and-fido-authentication...). - Softkeys are available—in fact, iOS, Android, MacOS, and Windows 11 all do webauthn by default, without the need for a hardware token.
  - dcow 5y ago
    And what’s left is essentially wireguard for logins. People love wireguard for its simplicity because it doesn’t use certs and PAKEs and whatnot. Yeah there are valid criticisms and I’ve critiqued the work as well in other comments. But the “this is utter shit how could anyone imagine this is a valid idea” is not productive. > Honestly, this discussion isn’t worth the time. That’s my point. If it’s not worth your time then let others who are interested discuss rather than just pissing all over the author’s project. > - Softkeys are available—in fact, iOS, Android, MacOS, and Windows 11 all do webauthn by default, without the need for a hardware token. That’s not soft keys it’s “platform authenticator”. When I say softkeys I mean keys managed by a user agent such that they can be portable, like is common with ssh. SSH is popular because it’s gives users the freedom to easily elect their security posture: do they want a user key that can be deployed to different devices or are they super paranoid and want a device key. Do they want a software agent to manage soft keys for them and it can handle the device security and hardware crypto engine support. Not your concern, not the protocols concern, not the services concern: it’s the user’s concern. Wireguard has soft keys, too. WebAuthn’s crowd and browser implementers on the other hand seem fixated on making sure users never have the option to deploy the protocol in such a way. That’s the problem.
    - md_ 5y ago
      > People love wireguard for its simplicity because it doesn’t use certs and PAKEs and whatnot. I don't know of a VPN that uses PAKE, so I don't get this comparison, but whatever. My point about certs was that OP was effectively proposing self-signed X509 client certs. It's unclear to me in what way those are harder to use than the proposal here, except that they actually are a widely accepted standard with user agent support. > WebAuthn’s crowd and browser implementers on the other hand seem fixated on making sure users never have the option to deploy the protocol in such a way. That’s the problem. https://github.com/herrjemand/awesome-webauthn#software-authenticators https://github.com/herrjemand/awesome-webauthn#software-auth...?

by md_ 5y ago

dcow 5y ago

Your tone is overly dismissive. If you want to be constructive then have a constructive conversation and not a dismissive knee jerk reaction. Your comment reads like “I haven’t read a standard for this or bothered to really take a look and it’s new therefore it’s fundamentally bad and insecure and not worth my time”. This repo is simply proposing using signed timestamps for auth. It would be nice to keep the discussion on that topic and it’s merits. Personally I think webauthn is not too complex and just needs to not be locked up in browser land so we can have a real softkey impl so we probably actually agree on our general outlook. You’re just kind a being a security diva about the whole thing and it’s not really fair to the author.

md_ 5y ago
Which part was knee jerk? I read everything on the (minimal) webpage. It doesn’t explain anything of substance, nor does it anticipate the (obvious) issues other commenters here noted. It’s like the author just proposed to remove everything they didn’t understand from Webauthn and was left with this. Honestly, this discussion isn’t worth the time. As for software webauthn keys: - What do you mean “locked up in browser land?” You can use FIDO elsewhere (e.g. ssh https://ubuntu.com/blog/enhanced-ssh-and-fido-authentication-in-ubuntu-20-04-lts https://ubuntu.com/blog/enhanced-ssh-and-fido-authentication...). - Softkeys are available—in fact, iOS, Android, MacOS, and Windows 11 all do webauthn by default, without the need for a hardware token.
- dcow 5y ago
  And what’s left is essentially wireguard for logins. People love wireguard for its simplicity because it doesn’t use certs and PAKEs and whatnot. Yeah there are valid criticisms and I’ve critiqued the work as well in other comments. But the “this is utter shit how could anyone imagine this is a valid idea” is not productive. > Honestly, this discussion isn’t worth the time. That’s my point. If it’s not worth your time then let others who are interested discuss rather than just pissing all over the author’s project. > - Softkeys are available—in fact, iOS, Android, MacOS, and Windows 11 all do webauthn by default, without the need for a hardware token. That’s not soft keys it’s “platform authenticator”. When I say softkeys I mean keys managed by a user agent such that they can be portable, like is common with ssh. SSH is popular because it’s gives users the freedom to easily elect their security posture: do they want a user key that can be deployed to different devices or are they super paranoid and want a device key. Do they want a software agent to manage soft keys for them and it can handle the device security and hardware crypto engine support. Not your concern, not the protocols concern, not the services concern: it’s the user’s concern. Wireguard has soft keys, too. WebAuthn’s crowd and browser implementers on the other hand seem fixated on making sure users never have the option to deploy the protocol in such a way. That’s the problem.
  - md_ 5y ago
    > People love wireguard for its simplicity because it doesn’t use certs and PAKEs and whatnot. I don't know of a VPN that uses PAKE, so I don't get this comparison, but whatever. My point about certs was that OP was effectively proposing self-signed X509 client certs. It's unclear to me in what way those are harder to use than the proposal here, except that they actually are a widely accepted standard with user agent support. > WebAuthn’s crowd and browser implementers on the other hand seem fixated on making sure users never have the option to deploy the protocol in such a way. That’s the problem. https://github.com/herrjemand/awesome-webauthn#software-authenticators https://github.com/herrjemand/awesome-webauthn#software-auth...?