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

41–50 of 85 posts

Re: Login with a Public Ed25519 Key

#41

Post by md_ »

_pzht wrote: post #39
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…

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.

It might help if you described a bit more explicitly your problem statement, threat model, and goals.

Re: Login with a Public Ed25519 Key

#42

Post by quickthrower2 »

I love the effort. Using a password for so much stuff these days just seems insane forcing me to remember a lot of passwords or be bogged down with a password manager.

Relying on google auth is too risky as google can just pull the carpet on any user. I do like a key management type solution with a backup factor like maybe emails and phones (2 of N kinda thing) if keys get lost. Google Authenticator (ironically!) would be a cool way to do it and keep sites siloed while using the same mechanism to log into each of them.

For many things a “scan this qr on your phone to log in” type mechanism linked to a key management app that calls an endpoint would be ideal - we tend to keep our phones working, charged and functioning in these post pandemic days. In Australia you can have your vax, covid check in, driving license, credit card of course, and various government vouchers all on the phone.

As much as I hate that for various 1984ish reasons, Im glad iPhone exists and is privacy centric, fairly robust and secure and with something like GA I feel quite safe logging into most sites that kind of way. Guess I am spoilt that an iPhone isn’t financially a stretch, i hope key chain type devices can be sold for $1 and stuck on your keyring with 12 words in a safe place for those who cant afford this luxury. I have’t looked into it.

I could then share authentication for certain things like say amazon prime with trusted people. There is this middle ground between individual and corporate (families/startups/friendship groups) that would be catered for here.

Tldr; passwords suck!

Re: Login with a Public Ed25519 Key

#44

Post by _pzht »

md_ wrote: post #41
_pzht wrote: post #39

Earlier quoted context omitted.

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.

It might help if you described a bit more explicitly your problem statement, threat model, and goals.

The demo website and the github repo contain this information. It would be helpful, if people actually created a key pair and tried to use it and misuse it before being critical.

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.

Re: Login with a Public Ed25519 Key

#45

Post by md_ »

_pzht wrote: post #44
md_ wrote: post #41

Earlier quoted context omitted.

It might help if you described a bit more explicitly your problem statement, threat model, and goals.

The demo website and the github repo contain this information. It would be helpful, if people actually created a key pair and tried to use it and misuse it before being critical. 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.

I read the github readme. It doesn't explain the problem or threat model in any detail.

My comment has nothing to do with federation or SSO, so I'm not sure why you mentioned those?

Re: Login with a Public Ed25519 Key

#46

Post by md_ »

octoberfranklin wrote: post #24
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…

> - 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 This is a (privacy) feature, not a bug. It forces you to use a different public key for each website.

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.

Re: Login with a Public Ed25519 Key

#47

Post by _pzht »

md_ wrote: post #45
_pzht wrote: post #44

Earlier quoted context omitted.

The demo website and the github repo contain this information. It would be helpful, if people actually created a key pair and tried to use it and misuse it before being critical. 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.

I read the github readme. It doesn't explain the problem or threat model in any detail. My comment has nothing to do with federation or SSO, so I'm not sure why you mentioned those?

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

Re: Login with a Public Ed25519 Key

#48

Post by md_ »

_pzht wrote: post #47
md_ wrote: post #45

Earlier quoted context omitted.

I read the github readme. It doesn't explain the problem or threat model in any detail. My comment has nothing to do with federation or SSO, so I'm not sure why you mentioned those?

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

Re: Login with a Public Ed25519 Key

#49

Post by octoberfranklin »

md_ wrote: post #46
octoberfranklin wrote: post #24

Earlier quoted context omitted.

> - 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 This is a (privacy) feature, not a bug. It forces you to use a different public key for each website.

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

Re: Login with a Public Ed25519 Key

#50

Post by _8j50 »

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 (usb,etc... pw encrypted)

- what makes this better than using mutual TLS auth?

I know i posted late, hope you see this OP.

Post reply on HN