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

51–60 of 85 posts

Re: Login with a Public Ed25519 Key

#51

Post by md_ »

octoberfranklin wrote: post #49
md_ wrote: post #46

Earlier quoted context omitted.

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.

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

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

Re: Login with a Public Ed25519 Key

#52

Post by octoberfranklin »

md_ wrote: post #51
octoberfranklin wrote: post #49

Earlier quoted context omitted.

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

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/googl…

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

Re: Login with a Public Ed25519 Key

#53

Post by 0xdeadb00f »

md_ wrote: post #36
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…

It’s worse. It encourages the use of the same strong “password” on every website?

I don't believe it does. The author is in this thread and keeps indisting the idea is to use a different ed25519 keypair for every site.

Re: Login with a Public Ed25519 Key

#54

Post by md_ »

octoberfranklin wrote: post #52
md_ wrote: post #51

Earlier quoted context omitted.

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/googl…

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

Re: Login with a Public Ed25519 Key

#55

Post by Xylakant »

0xdeadb00f wrote: post #53
md_ wrote: post #36

Earlier quoted context omitted.

It’s worse. It encourages the use of the same strong “password” on every website?

I don't believe it does. The author is in this thread and keeps indisting the idea is to use a different ed25519 keypair for every site.

The idea may be, but then users will need to manage a key pair per site - and there’s less support for safely managing key pairs than there’s for passwords. How many people will actually do that, if the system doesn’t enforce it and how can the system enforce such a constraint?

Re: Login with a Public Ed25519 Key

#56

Post by Robert4757 »

md_ wrote: post #34
hn_throwaway_99 wrote: post #16

Earlier quoted context omitted.

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

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

No post body was provided.

Re: Login with a Public Ed25519 Key

#57

Post by md_ »

Xylakant wrote: post #55
0xdeadb00f wrote: post #53

Earlier quoted context omitted.

I don't believe it does. The author is in this thread and keeps indisting the idea is to use a different ed25519 keypair for every site.

The idea may be, but then users will need to manage a key pair per site - and there’s less support for safely managing key pairs than there’s for passwords. How many people will actually do that, if the system doesn’t enforce it and how can the system enforce such a constraint?

I think if I'm being generous, the proposal is to eventually have a credential management ecosystem (with cross-device key syncing, and keys per origin) similar to WebAuthn.

However, if you do this, you rapidly start to discover some of the reasons behind WebAuthn's design choices. For example, to prevent phishing/replay/linkage, the "authenticator" (the thing managing the keys) has to know the origin/RP. And to allow hardware and software authenticators, you need some protocol like CTAP to abstract that out. And because some RPs want to require hardware-backed or biometric authenticators, you need an authenticator type. Etc, etc, etc.

If WebAuthn is hard to use, it's because we haven't build the right libraries and abstractions yet, and that indeed sucks. (Though I think we mostly have, and it's not that hard to use.)

But the criticism here of complexity--contrasted with the simplicity of a trivially broken, horribly unusable "proof of concept"--is a bit like someone who says "I can make a working demo of a car without power steering, antilock breaks, an entertainment unit, an ECU, a catalytic converter, or headlights--just four wheels and a two-stroke engine! Clearly all that complexity isn't needed!"

Re: Login with a Public Ed25519 Key

#58

Post by megous »

_8j50 wrote: post #50

I've had similar ideas. A few suggestions: - sign a challenge instead of a timestamp - Make it effortless by using the FileSystem api to permanently point to a specific file on the device (until they move it) - Use webcrypto to do the signing in-browser - You can store a master private key that certifies new devices and can revoke old keys on the user's behalf or have them agree to generate one and store it off like…

I've had similar ideas, too. But I just ended up using randomly generated email address and password per website, which does two things for me: resistance against password resets (noone knows what email to put into a password reset form) and credential stuffing.

Author's solution adds some auth re-play protection, compared to what I use. But that's very little additional protection against threats that would be hardly a problem in practice for me. I just use TLS to protect the auth interaction (so who's going to capture the credentials?).

Most importantly, passwords actually work almost everywhere.

Re: Login with a Public Ed25519 Key

#59

Post by tialaramex »

md_ wrote: post #51
octoberfranklin wrote: post #49

Earlier quoted context omitted.

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

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/googl…

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.

Re: Login with a Public Ed25519 Key

#60

Post by pornel »

_pzht wrote: post #40
jmwilson wrote: 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.

"Simpler" is a weasel word that can either mean "easier" or "more primitive", and in this case it's the latter.

Webauthn doesn't require separate keys per site and user vigilance to stay secure, because it has a-not-so-simple challenge-response protocol that is site-specific. For end users Webauthn is easier to use: just press a foolproof button.

I don't want to sound too negative. ed25519 keys are neat, and have fun implementing software using them. Let's just be realistic that a practical cryptographic system needs many more features, and Webauthn has them for a reason.

Post reply on HN