[srfilipek]

It's an okay-ish alternative to a password, but if we're going to use cryptographic secrets for auth, I'd hope to see more of a handshake and challenge-response involved.

As it stands, anyone who has access to a private key momentarily can generate any number of tokens for use, practically indefinitely (just sign a timestamp for every second for the next N years). This system is open to replay attacks as well.

It also glosses over the entire problem of trust establishment, cert revocation, etc.

[IncRnd]

I take an even dimmer view of this. First, the author is wrong on the premise let alone the implementation. This is not logging in with a public key but by using a keypair. This scheme actually moves from something you know to something you have. For that reason alone it can weaken or break two factor auth schemes.

Since it is akin to device not user authentication, the keypair may be copied between machines and suffer the intricacies of the details used to do so, weakening the keypair FOR ITS ENTIRE FUTURE LIFETIME. Replay attacks are trivial to perform.

It's a nice idea that is well explored elsewhere, but this should not even be considered an implementation of how to login into a system. This is not user authentication, even ignoring its flaws. This is auth for the device on which the keypair resides. Crypto is easy to get wrong even for experts.

[_pzht]

The web service stores used signatures. They cannot be re-used and are only good for about 30 seconds. Try to register on the demo site and see if you can actually replay a signature.

[dcow]

Which is a naive way to implement reuse mitigation because you have have a db that grows endlessly. Send a nonce and have the user sign it. Make sure the nonce is only valid for one use (burn it after it’s used). Then you only have to remember active nonces and you can expire them after a short interval.

[_pzht]

Used signatures are purged from the DB after they are no longer valid (too much time has passed). I realize this is a naive, toy implementation (in general). I wrote it to have a broader discussion.

[ghusbands]

You've got the problem that a lot of people have tried to create a lot of novel cryptographic protocols, and they are almost always lacking and insecure. It becomes useful to be able to quickly dismiss things that seem uninformed, as nobody has time to read every such thing.

The inclusion of a nonce/challenge (and other chosen-text and offline-attack mitigations) helps with a lot of security flaws, and that you've omitted them for no clear reason undermines your position as creator of a novel protocol.

As a trivial example, imagine that someone else comes up with a protocol that uses a signed current-date to authorise a bank transfer; as it's not distinguishable from your protocol, there would be many avenues for tricking a user into providing you with the ability to steal their money.

In responses elsewhere in the thread, you say that users should have a public key per website, but in your readme, you repeatedly imply that users have a single key-pair. "Register your base64 encoded public Ed25519 key with the website." "Use your private Ed25519 key to sign the current Unix Epoch Time" "Websites store the users' public keys."

Requiring users to keep generating keys and manage them manually introduces insecurity through non-compliance. It's not simple if you've got to manage something that behaves entirely like a local password database.

You say elsewhere "The demo website and the github repo contain this information" - but the demo website has no descriptive text (can you perhaps provide a link?) and the readme barely mentions threat models or goals. How do you prevent MitM attacks? Can your design support multi-party authentication or delegation of any kind?

I have no experience with WebAuthn, but it's likely that a lot of its features are to improve security in many ways, and omitting these features might make things easier at request-protocol level, but perhaps just simplistic overall.

You say you're trying to facilitate a conversation, but the proposal is so basic that you're effectively asking people to create a useful protocol for you.

[dcow]

You might want to look at webauthn since you say you’re unfamiliar. It’s not much more than a signed nonce with relying party domain name. It actually isn't that complicated. I don’t feel like the author is asking people to implement a protocol for them. They just maybe could have done some research into why WebAuthn has the complexities it does and presented a compelling argument in the readme for why they think they’re overkill or not necessary.

[_pzht]

I like the idea of signing a nonce rather than the current time. That solves several problems. Thanks for the advice.

[dcow]

Time is just icky. I have a personal requirement/standard that I never depend on wall clocks in software I design. Timestamps can be used as an optimization, sure. But never as a fundamental component in the protocol or system.