Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Login with a Public Ed25519 Key

github.com

Post reply on HN
Print view View original

11–20 of 85 posts

Re: Login with a Public Ed25519 Key

#11

Post by IncRnd »

srfilipek wrote: post #6

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 als…

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.

Re: Login with a Public Ed25519 Key

#12

Post by woodruffw »

As far as I can tell, there's no nonce (for replays) or counter (for stolen keys) in this scheme, both of which are fundamental to the security model that WebAuthn provides. There's also no formal sliding window for server times or key timeliness constraints.

In many regards, this scheme is no better than a strong password in terms of guarantees provided. In terms of UX, it's strictly worse than a password (and those are already pretty bad!) It's not a second factor at all, and thus isn't really an "alternative" to WebAuthn.

Re: Login with a Public Ed25519 Key

#13

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

Re: Login with a Public Ed25519 Key

#15

Post by woodruffw »

jazzyjackson wrote: post #5
redleader55 wrote: post #3

This is very likely insecure. A malicious web site could replay your Auth flow to another website where you have an account that uses the same keypair.

right, would be better for the site to encrypt a one-time-use password with the public key you've, then all you have to do is decrypt it and log in, proving you possess the private key does this have a name? always seemed like the obvious way to do it but I've never implemented auth edit: I guess this is similar to a challenge/sign/verify signature scheme like webauthen, but is it inferior in some way?

Yep, what you've described is pretty close to the scheme in WebAuthn. The main additions in WebAuthn are for protocol level security: there's an attestation nonce, a shared counter, and some other fiddly bits to make it harder/impossible to misuse.

Re: Login with a Public Ed25519 Key

#16

Post by hn_throwaway_99 »

yuliyp wrote: post #13

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, an…

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

Re: Login with a Public Ed25519 Key

#17

Post by asojfdowgh »

An easier, more secure approach, would be

    authviassh://authviassh@auth.server/origin.domain/nonce
parsed restrictively

    authviassh:\/\/authviassh@(${domain_regex})/(${domain_regex})/([0-9a-zA-Z]+)
prompting the user:

    "Would you like to log into origin.domain (via auth.server) using ~/.ssh/your_key?"
and then finally running

    ssh "authviassh@auth.server" -- authviassh "origin.domain" "nonce"
with the appropriate additional flags to turn off forwarding et al

Only problem is, only 1 language has decent bindings for ssh interactives server-side, so one is somewhat forced to learn Go to implement this easily

Re: Login with a Public Ed25519 Key

#18

Post by staticassertion »

woodruffw wrote: post #12

As far as I can tell, there's no nonce (for replays) or counter (for stolen keys) in this scheme, both of which are fundamental to the security model that WebAuthn provides. There's also no formal sliding window for server times or key timeliness constraints. In many regards, this scheme is no better than a strong password in terms of guarantees provided. In terms of UX, it's strictly worse than a password (and those…

Yes, this looks like it's just a worse version of passwords.

Re: Login with a Public Ed25519 Key

#20

Post by staticassertion »

jazzyjackson wrote: post #5
redleader55 wrote: post #3

This is very likely insecure. A malicious web site could replay your Auth flow to another website where you have an account that uses the same keypair.

right, would be better for the site to encrypt a one-time-use password with the public key you've, then all you have to do is decrypt it and log in, proving you possess the private key does this have a name? always seemed like the obvious way to do it but I've never implemented auth edit: I guess this is similar to a challenge/sign/verify signature scheme like webauthen, but is it inferior in some way?

SRP, PAKE, and OPAQUE. More generally, zero knowledge proofs (ZKP).
Post reply on HN