8 ms·

This feels very broken: - The suggestion of signing the timestamp means that any web site you log into with this can log in as you to any other web site you lo

by yuliyp 5y ago

This feels very broken: - The suggestion of signing the timestamp means that any web site you log into with this can log in as you to any other web site you log in to - Given that there's no namespacing of the signed messages, users can be easily phished into providing a response to a challenge posed by a different web site - It's not obvious what advantages this has over using client cert authentication with TLS, and it has many downsides.

hn_throwaway_99 5y ago
> Given that there's no namespacing of the signed messages, users can be easily phished into providing a response to a challenge posed by a different web site This is key. The whole benefit of hardware token-based authentication is that it is resistant against phishing (because SMS 2-factor and TOTP, e.g. Google Authenticator, are NOT phishing resistant). So this approach is more complicated than those other 2 2FA approaches but with no additional security benefit.
- gruez 5y ago
  >The whole benefit of hardware token-based authentication [...] Technically it's not something limited to hardware tokens. You can conceivably do something similar with username/password authentication, as long as the credentials are sent to the browser and not the site.
- md_ 5y ago
  As the other commenter said, this has nothing to do with hardware tokens. This has to do with the user agent (the browser) passing the (browser-verified) origin to the authenticator (which can be hardware or software). But, critically, the signatures are also origin-scoped—the message that your user-agent correctly passes to google.com cannot be used by google to sign into microsoft.com. What’s broken here is not that user agents are or aren’t validating the origin (or relying party)—it’s that the same key+challenge is used for every origin. (As a result, there’s nothing for the user agent to validate, because the same signature is used for all origins!) It’s like using the same password for every website you log into. As severe understatement, this is a very, very bad protocol design, and nobody should use it.
  - Robert4757 5y ago
octoberfranklin 5y ago
> - The suggestion of signing the timestamp means that any web site you log into with this can log in as you to any other web site you log in to This is a (privacy) feature, not a bug. It forces you to use a different public key for each website.
- deleted 5y ago
  [deleted]
- md_ 5y ago
  FIDO keys are also unlinkable across origins (or identities!), but unlike in this scheme, that property doesn't rely on the user knowing to not reuse keys. Anyway, unclear to me how this is better than x509 client certs, except that the author probably doesn't know about them.
  - octoberfranklin 5y ago
    Device attestation certificates, for starters. FIDO prevents user-controlled hardware. That's the whole point of FIDO, and why it's awful. FIDO is the banking world's version of the Intel Management Engine and HDCP. https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-RD-v1.0-20201202.html#device-attestation https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-RD-v1...
    - md_ 5y ago
      I'm not sure what you're replying to--this scheme is much closer to self-signed X509 client certs, not FIDO. But regarding FIDO, it does not prevent user-controlled hardware; it's up to RPs to choose if they require specific device manufacturers or not. In my experience, the vast majority of (consumer) RPs do not require specific batch attestation, which is why you can make your own FIDO key: https://github.com/google/OpenSK https://github.com/google/OpenSK. I am under the impression support for attestation was controversial in FIDO--it's clearly useful for enterprise scenarios (e.g. where an enterprise requires some silly certification like FIPS: https://support.yubico.com/hc/en-us/articles/360016614760-Achieving-FedRamp-Compliance-with-the-YubiKey-FIPS-Series-Devices https://support.yubico.com/hc/en-us/articles/360016614760-Ac...), but there's always the risk that consumer-facing RPs require it for no good reason. My employer requires FIPS certification due to FedRAMP; I'd be interested in how you would propose to change FIDO such that--as now--I can use a single key for work and for all my consumer needs while eliminating attestation. (One obvious option is for my employer to issue already-enrolled keys and disallow self-enrollment, but that has other headaches...)
_pzht 5y ago
This is not meant for SSO. Signatures are only valid for about 30 - 60 seconds (depending on the server config) and may not be re-used after a successful login. Try to create a key pair and log into the test website. Then try to use the same signature to do so again.
- md_ 5y ago
  It might help if you described a bit more explicitly your problem statement, threat model, and goals.
  - _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.

by yuliyp 5y ago

hn_throwaway_99 5y ago

> Given that there's no namespacing of the signed messages, users can be easily phished into providing a response to a challenge posed by a different web site This is key. The whole benefit of hardware token-based authentication is that it is resistant against phishing (because SMS 2-factor and TOTP, e.g. Google Authenticator, are NOT phishing resistant). So this approach is more complicated than those other 2 2FA approaches but with no additional security benefit.

gruez 5y ago
>The whole benefit of hardware token-based authentication [...] Technically it's not something limited to hardware tokens. You can conceivably do something similar with username/password authentication, as long as the credentials are sent to the browser and not the site.
md_ 5y ago
As the other commenter said, this has nothing to do with hardware tokens. This has to do with the user agent (the browser) passing the (browser-verified) origin to the authenticator (which can be hardware or software). But, critically, the signatures are also origin-scoped—the message that your user-agent correctly passes to google.com cannot be used by google to sign into microsoft.com. What’s broken here is not that user agents are or aren’t validating the origin (or relying party)—it’s that the same key+challenge is used for every origin. (As a result, there’s nothing for the user agent to validate, because the same signature is used for all origins!) It’s like using the same password for every website you log into. As severe understatement, this is a very, very bad protocol design, and nobody should use it.
- Robert4757 5y ago

octoberfranklin 5y ago

> - The suggestion of signing the timestamp means that any web site you log into with this can log in as you to any other web site you log in to This is a (privacy) feature, not a bug. It forces you to use a different public key for each website.

deleted 5y ago
[deleted]
md_ 5y ago
FIDO keys are also unlinkable across origins (or identities!), but unlike in this scheme, that property doesn't rely on the user knowing to not reuse keys. Anyway, unclear to me how this is better than x509 client certs, except that the author probably doesn't know about them.
- octoberfranklin 5y ago
  Device attestation certificates, for starters. FIDO prevents user-controlled hardware. That's the whole point of FIDO, and why it's awful. FIDO is the banking world's version of the Intel Management Engine and HDCP. https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-RD-v1.0-20201202.html#device-attestation https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-RD-v1...
  - md_ 5y ago
    I'm not sure what you're replying to--this scheme is much closer to self-signed X509 client certs, not FIDO. But regarding FIDO, it does not prevent user-controlled hardware; it's up to RPs to choose if they require specific device manufacturers or not. In my experience, the vast majority of (consumer) RPs do not require specific batch attestation, which is why you can make your own FIDO key: https://github.com/google/OpenSK https://github.com/google/OpenSK. I am under the impression support for attestation was controversial in FIDO--it's clearly useful for enterprise scenarios (e.g. where an enterprise requires some silly certification like FIPS: https://support.yubico.com/hc/en-us/articles/360016614760-Achieving-FedRamp-Compliance-with-the-YubiKey-FIPS-Series-Devices https://support.yubico.com/hc/en-us/articles/360016614760-Ac...), but there's always the risk that consumer-facing RPs require it for no good reason. My employer requires FIPS certification due to FedRAMP; I'd be interested in how you would propose to change FIDO such that--as now--I can use a single key for work and for all my consumer needs while eliminating attestation. (One obvious option is for my employer to issue already-enrolled keys and disallow self-enrollment, but that has other headaches...)

_pzht 5y ago

This is not meant for SSO. Signatures are only valid for about 30 - 60 seconds (depending on the server config) and may not be re-used after a successful login. Try to create a key pair and log into the test website. Then try to use the same signature to do so again.

md_ 5y ago
It might help if you described a bit more explicitly your problem statement, threat model, and goals.
- _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.