5 ms·

The demo website and the github repo contain this information. It would be helpful, if people actually created a key pair and tried to use it and misuse it befo

by _pzht 5y ago

The demo website and the github repo contain this information. It would be helpful, if people actually created a key pair and tried to use it and misuse it before being critical. It's not meant for federation, single-sign on (which is single compromise IMPO) or anything that is commonly discussed in the security community. It's foreign to most (I understand that), and I just wanted to share it and start a discussion.

md_ 5y ago
I read the github readme. It doesn't explain the problem or threat model in any detail. My comment has nothing to do with federation or SSO, so I'm not sure why you mentioned those?
- _pzht 5y ago
  Because it was in reply to my earlier comment saying this is not SSO. People seem to think these signatures can be used on multiple websites (sign in with Google like functionality). That's not the case. These signatures are meant to be used to authenticate to a website. If multiple websites implement this idea, then end users should have multiple key pairs (one for each site). So there would be no way a signature for one site could be misused or abused on another. I believe the github site and the demo website do describe the problem and goals. Webauthn is too complex. Passwords are bad. Hashes are dumped from databases and cracked. Passwords are stuffed, etc. The complexity of webauthn is not the answer. In this scheme, the website only knows its users' public Ed25519 keys. These keys are harmless and it does not matter if they are stolen (they cannot be used to cause any harm). The users are in full control of the keys. There is no CA signing TLS certs, etc. The web service and its users are in full control of the process and they are using open-source software. Full transparency that is easily understood by all parties. Also, there is no identifying information in an Ed25519 key. One goal I have is user anonymity. This scheme allows for that too. No email, phone, etc. Just a public Ed25519 key fully controlled by its end user.
  - 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.

by _pzht 5y ago

md_ 5y ago

I read the github readme. It doesn't explain the problem or threat model in any detail. My comment has nothing to do with federation or SSO, so I'm not sure why you mentioned those?

_pzht 5y ago
Because it was in reply to my earlier comment saying this is not SSO. People seem to think these signatures can be used on multiple websites (sign in with Google like functionality). That's not the case. These signatures are meant to be used to authenticate to a website. If multiple websites implement this idea, then end users should have multiple key pairs (one for each site). So there would be no way a signature for one site could be misused or abused on another. I believe the github site and the demo website do describe the problem and goals. Webauthn is too complex. Passwords are bad. Hashes are dumped from databases and cracked. Passwords are stuffed, etc. The complexity of webauthn is not the answer. In this scheme, the website only knows its users' public Ed25519 keys. These keys are harmless and it does not matter if they are stolen (they cannot be used to cause any harm). The users are in full control of the keys. There is no CA signing TLS certs, etc. The web service and its users are in full control of the process and they are using open-source software. Full transparency that is easily understood by all parties. Also, there is no identifying information in an Ed25519 key. One goal I have is user anonymity. This scheme allows for that too. No email, phone, etc. Just a public Ed25519 key fully controlled by its end user.
- 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.