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.
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.
My comment has nothing to do with federation or SSO, so I'm not sure why you mentioned those?
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.
> 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.
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...).
- Softkeys are available—in fact, iOS, Android, MacOS, and Windows 11 all do webauthn by default, without the need for a hardware token.
> 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.
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-auth...?
You are correct that client certs have user agent support. Honestly it’s a pretty poor UX though. Have you actually tried building a consumer application that uses client certs in the browser? Good luck getting users to install client certs. Client certs work fine everywhere else where you can run bespoke client software (native apps) except for the part where they authenticate the connection and not the request, but that’s not the point either.
Anyway it’s great that other implementations of webauthn exist. But like I just said for client certs: outside of the browser anyone can do anything so webauthn is not a game changer there (not to downplay it). Where WebAuthn matters is for client authentication in the browser and in that arena it is locked down to platform auth and hardware device auth mechanisms. There is no way users could benefit from webauthn right now without the browser-supplied UX.
All I’m saying is that WebAuthn would be way more viable in the way people are asking for in this thread if for example browsers/platforms allowed extensions to participate as a soft WebAuthn agent so that users could choose their preferred WebAuthn backend and UX instead of the browser supplied options. The browser client cert UX sucks and so does browser vendor WebAuthn and I think their adoption story is all the proof you need.
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.