Live data from Hacker News

Login with a Public Ed25519 Key

github.com

61–70 of 85 posts

Re: Login with a Public Ed25519 Key

#61

As many have noted, this scheme is simple only because its only goal is to replace passwords, while seemingly ignoring even common security threats. Reminds me of TripleSec : https://news.ycombinator.com/item?id=9655245 As good as WebAuthn is, research around PAKE s is currently the most exciting to me: https://blog.cloudflare.com/research-directions-in-password-...

I agree that the proposed solution has many flaws, and that PAKE is much more promising than any plain password-based scheme. As another commenter pointed out, OPAQUE is very interesting.

I just wish browsers natively supported that authentication scheme to further defend against phishing and other attacks where the javascript implementation can be replaced.

Re: Login with a Public Ed25519 Key

#62
post #40
post #4

"Much simpler than webauthn" Is it? Trying out https://webauthn.io/ , I can log in using a security key without hitting the command line and copy & pasting some base64 string. "Private keys never leave end users' devices" How does it guarantee that, considering it saves the private key in the file system? It can be trivially copied off device from there. The examples also appear to encourage key reuse, and since the…

Users can have a different key pair for each website. Also, signatures may not be re-used and are only valid for a few seconds. Try to create a key pair and login to the test website.

Users demonstrably reuse credentials across systems. If you are relying on users to always create a new key pair for each service, they simply won’t do that.

A few seconds is plenty of time for an automated system to cause harm.

Re: Login with a Public Ed25519 Key

#63
post #31

Earlier quoted context omitted.

What's stopping an idiot from doing so?

The fact that it's a bare-bones technical demonstration and an idiot would have no wherewithal or purpose to implement it.

But then what's it actually demonstrating? That public key cryptography can be used to...validate that someone has a private key?

I feel like I knew that already. ;)

Re: Login with a Public Ed25519 Key

#64
post #22

I feel like this demo is just a conversation starter and not a serious attempt at a login scheme. Like, signing and verifying using ed25519 is not hard and adding a CLI to do some crypto operations is not novel. If someone was implementing this they wouldn't shell out anyway since there is very good library support in . The only thing WebAuthn needs to figure out is soft keys. Users don't want to enroll devices they…

> Users don't want to enroll devices they want to log in with face/touch ID. The webauthn UX is broken and needs to be revamped so that users can choose a not technically perfect but still effective and better than passwords security posture where they reuse a soft webauthn key across devices. I'm not sure I understand the problem here. WebAuthn is entirely agnostic about the physical factor: it can be a hardware key…

The problem is device enrollment. I am saying users want to use FaceID to log in like they currently use a password. They don't want to enroll devices with a service. Browsers don’t support software webauthn so the fact that it can happen is kinda moot. The existing browser-controlled implementation of the UX is what I’m complaining about. There’s this assumption in the security community that users need hardware backed crypto and soft keys with an agent in-between aren’t acceptable. I’m saying for most all users a soft-key setup backed by hardware primitives works just fine and is better than password auth but lamenting that it’s unlikely we’ll see support it because of platform control under the guise of better security.

Think of it this way, users would be better off with ssh style login instead of passwords but the “industry” seems to have skipped that step for consumers and gone straight to hardware keys.

Re: Login with a Public Ed25519 Key

#65
post #39
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…

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.

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

Re: Login with a Public Ed25519 Key

#66
post #48
post #47

Earlier quoted context omitted.

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

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…

Your tone is overly dismissive. If you want to be constructive then have a constructive conversation and not a dismissive knee jerk reaction. Your comment reads like “I haven’t read a standard for this or bothered to really take a look and it’s new therefore it’s fundamentally bad and insecure and not worth my time”. This repo is simply proposing using signed timestamps for auth. It would be nice to keep the discussion on that topic and it’s merits. Personally I think webauthn is not too complex and just needs to not be locked up in browser land so we can have a real softkey impl so we probably actually agree on our general outlook. You’re just kind a being a security diva about the whole thing and it’s not really fair to the author.

Re: Login with a Public Ed25519 Key

#67
post #38

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…

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.

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.

Re: Login with a Public Ed25519 Key

#68
post #66
post #48

Earlier quoted context omitted.

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…

Your tone is overly dismissive. If you want to be constructive then have a constructive conversation and not a dismissive knee jerk reaction. Your comment reads like “I haven’t read a standard for this or bothered to really take a look and it’s new therefore it’s fundamentally bad and insecure and not worth my time”. This repo is simply proposing using signed timestamps for auth. It would be nice to keep the discussi…

Which part was knee jerk? I read everything on the (minimal) webpage. It doesn’t explain anything of substance, nor does it anticipate the (obvious) issues other commenters here noted. It’s like the author just proposed to remove everything they didn’t understand from Webauthn and was left with this.

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.

Re: Login with a Public Ed25519 Key

#69
post #67
post #38

Earlier quoted context omitted.

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.

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.

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.

Re: Login with a Public Ed25519 Key

#70
post #54

Earlier quoted context omitted.

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

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

Because for consumer auth we just go back to the CA oligarchy and client certs nobody uses if we rely on trusting vendor attestation.

I understand for a corporate setup employees are threat vectors. But that depressing outlook isn't how most people view the consumer space. We want: consumer x signed this auth challenge. We do not want: authority Y said consumer X signed this auth challenge. That’s just CA SSO style oligarchy repeated.

Why wouldn't you trust the consumer and their preferred authentication agent to participate in an authentication challenge? Consumer apps don’t need to ensure that consumers are using a hardware token device they just need to arrange an authentication dance that doesn't involve a shared secret.

Post reply on HN