[yuliyp]

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]

> 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.

[md_]

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.

[gruez]

>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.

[_pzht]

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_]

It might help if you described a bit more explicitly your problem statement, threat model, and goals.

[_pzht]

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_]

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]

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.

[Zamicol]

Are you the author? If so I would love to talk with you more about your vision and goals.

I personally would like reusable keys, and I agree namespace or some other mechanism is needed.

I generally prefer to link my identity among websites and I'm generally not concerned about anonymity or privacy. "A key for each website" is nearly worthless to me.

The ability of others to spoof my identity because a website uses passwords, and most websites provide little to no logging, let alone a standardization, infuriates me. That is a outsized use case I see little attention given to.

If I tweet, users are forced to trust Twitter's authentication system that I tweeted. I don't trust Twitter's authentication systems.

Public key authentication permits third parties to verify my actions without the need to trust system authentication systems.

[md_]

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.

[KingOfCoders]

What does prevent google.com liging into Microsoft con within one millisecond after receiving the signature?

[octoberfranklin]

> - 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.

[md_]

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]

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...

[md_]

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.

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-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...)

[tialaramex]

The WebAuthn spec. explicitly tells RPs not to do this (attestation) unless they're sure they really need it.

Even Microsoft's half-arsed explanation of how this works inside Azure AD says you should probably not use it.

And I tell Firefox "No" when it asks me during enrollment if the site is allowed attestation from my devices, there are no public sites I've used where this was rejected as unacceptable, that includes GitHub, Google's sites, Facebook, and Login.gov.

[octoberfranklin]

> it's up to RPs to choose if they require specific device manufacturers or not.

The point is that it takes that choice out of the users' hands.

Choosing which manufacturer's hardware to use, or even to make their own, is the user's choice to make.

> use a single key for work and for all my consumer needs

You shouldn't. That's like expecting to be able to use your work laptop for personal stuff.

[md_]

> The point is that it takes that choice out of the users' hands.

Unclear to me why you think the user--and not the IdP--should have the final say here.

> You shouldn't. That's like expecting to be able to use your work laptop for personal stuff.

Except FIDO identities are unlinkable even if using the same hardware.

[Zamicol]

I want to be able to link my identity across website. I want to be able to have a key on my phone that's known as my phone key.