8 ms·

Login with a Public Ed25519 Key

97 points by _pzht 5y ago

qudat 5y ago
> Much simpler than webauthn. Having recently had to upgrade from u2f to webauthn, the complexity involved in getting webauthn right cannot be understated, especially when comparing it to something like OTP. This flow seems simpler but more annoying for the end-user, right? They would have to generate the signed message themselves and then paste it into the browser. Whereas with webauthn you just touch your security key.
- md_ 5y ago
  This flow is also insecure. Ideally, we make WebAuthn easier to use (via libraries, identity providers, etc), rather than, you know, replacing it with something less secure than passwords. Just sayin’. ;)
redleader55 5y ago
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.
- jazzyjackson 5y ago
  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?
  - woodruffw 5y ago
    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.
  - staticassertion 5y ago
    SRP, PAKE, and OPAQUE. More generally, zero knowledge proofs (ZKP).
    - jazzyjackson 5y ago
      thanks !
  - Lurkars 5y ago
    This is exactly what I use for an emailless password reset. Instead of sending a reset token via email, it's just encrypted with public key and user can decrypt token for reset password. There for I don't require to collect email address for account. Of course this could also be used as login method. On the downside, for UX purposes decryption can run in browser by passing private key. I have mixed feelings about pasting PKs into browser.
  - Zamicol 5y ago
    PoP, Proof-of-Possession.
- copperfoil 5y ago
  Yeah, there's no verification of a server's pubkey like ssh (which mostly is trust-on-first use), or a cert chain like tls. This seems like a cool proof-of-concept. There are also a bunch of security properties that it fails in.
- deleted 5y ago
  [deleted]
- addingnumbers 5y ago
  Why would you use the same keypair for multiple sites?
  - ikiris 5y ago
    What's stopping an idiot from doing so?
    - addingnumbers 5y ago
      The fact that it's a bare-bones technical demonstration and an idiot would have no wherewithal or purpose to implement it.
      - md_ 5y ago
        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. ;)
- Zamicol 5y ago
  It's the same for passwords. The advantage is that your private key can't be leaked on a third party website.
jmwilson 5y ago
"Much simpler than webauthn" Is it? Trying out https://webauthn.io/ 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 challenge is the current time, the signed auth message can be replayed against any other site where the user set up using the same key.
- _pzht 5y ago
  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.
  - pornel 5y ago
    "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.
  - UncleMeat 5y ago
    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.
srfilipek 5y ago
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 5y ago
  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 5y ago
  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 5y ago
    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.
    - 5y ago
ipnon 5y ago
This post has ironically convinced me to use WebAuthn instead.
- stavros 5y ago
  I really like WebAuthn, I only wish it were supported everywhere.
woodruffw 5y ago
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.
- staticassertion 5y ago
  Yes, this looks like it's just a worse version of passwords.
- md_ 5y ago
  It’s worse. It encourages the use of the same strong “password” on every website?
  - 0xdeadb00f 5y ago
    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.
    - Xylakant 5y ago
      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?
      - md_ 5y ago
        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!"
yuliyp 5y ago
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.
- hn_throwaway_99 5y ago
  > 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.
  - gruez 5y ago
    >The whole benefit of hardware token-based authentication [...] Technically it's not something limited to hardware tokens. You can conceivably do something similar with username/password authentication, as long as the credentials are sent to the browser and not the site.
  - md_ 5y ago
    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 that user agents are or aren’t validating the origin (or relying party)—it’s that the same key+challenge is used for every origin. (As a result, there’s nothing for the user agent to validate, because the same signature is used for all origins!) It’s like using the same password for every website you log into. As severe understatement, this is a very, very bad protocol design, and nobody should use it.
asojfdowgh 5y ago
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
- pxx 5y ago
  This seems similar in concept to https://github.com/michft/ssh-mars https://github.com/michft/ssh-mars or https://github.com/wes1138/webauth-via-ssh https://github.com/wes1138/webauth-via-ssh but you could imagine that the person running the SSH server doesn't necessarily need to be the person running the website.
staticassertion 5y ago
Lots of things are easier than webauthn if you don't provide the same guarantees.
dcow 5y ago
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 <insert your language of choice>. The only thing WebAuthn needs to figure out is soft keys. 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. If whatever agent handling the soft key encrypts it at rest using device keys you’re effectively isomorphic to “key never leaves the device”. It would be nice if hardware devices supported a non-resident key mode where you could give it an encrypted key and it would decrypt the key on device memory using an on-device key and then use the decrypted key for a crypto operation (encryption or signing). Then you could get a pretty much perfectly isomorphic experience with a non-resident key.
- inetknght 5y ago
  > Users don't want to enroll devices they want to log in with face/touch ID. Not all users. I'm a user. I want to log in with my SSH key because it's far more secure than my face or fingerprint.
  - dcow 5y ago
    Yeah sorry I should have qualified: average consumer users.
- woodruffw 5y ago
  > 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, a software implementation, TouchID/FaceID, or anything else. You can already use TouchID and FaceID on sites that use WebAuthn, and the UX is perfectly fine. You still have to enroll the device, but that's no different from the Face/TouchID UX in any other authentication context.
ignoramous 5y ago
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 https://news.ycombinator.com/item?id=9655245 As good as WebAuthn is, research around PAKEs is currently the most exciting to me: https://blog.cloudflare.com/research-directions-in-password-security/ https://blog.cloudflare.com/research-directions-in-password-...
- MayeulC 5y ago
  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.
pabs3 5y ago
This reminds me of TLS client certs.
quickthrower2 5y ago
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!
endorphine 5y ago
I was a bit disappointed that the "Advantages of this approach" section wasn't followed by a "Disadvantages of this approach".
_8j50 5y ago
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.
- megous 5y ago
  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.

97 points by _pzht 5y ago

> Much simpler than webauthn. Having recently had to upgrade from u2f to webauthn, the complexity involved in getting webauthn right cannot be understated, especially when comparing it to something like OTP. This flow seems simpler but more annoying for the end-user, right? They would have to generate the signed message themselves and then paste it into the browser. Whereas with webauthn you just touch your security key.

md_ 5y ago
This flow is also insecure. Ideally, we make WebAuthn easier to use (via libraries, identity providers, etc), rather than, you know, replacing it with something less secure than passwords. Just sayin’. ;)

redleader55 5y ago

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.

jazzyjackson 5y ago
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?
- woodruffw 5y ago
  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.
- staticassertion 5y ago
  SRP, PAKE, and OPAQUE. More generally, zero knowledge proofs (ZKP).
  - jazzyjackson 5y ago
    thanks !
- Lurkars 5y ago
  This is exactly what I use for an emailless password reset. Instead of sending a reset token via email, it's just encrypted with public key and user can decrypt token for reset password. There for I don't require to collect email address for account. Of course this could also be used as login method. On the downside, for UX purposes decryption can run in browser by passing private key. I have mixed feelings about pasting PKs into browser.
- Zamicol 5y ago
  PoP, Proof-of-Possession.
copperfoil 5y ago
Yeah, there's no verification of a server's pubkey like ssh (which mostly is trust-on-first use), or a cert chain like tls. This seems like a cool proof-of-concept. There are also a bunch of security properties that it fails in.
deleted 5y ago
[deleted]
addingnumbers 5y ago
Why would you use the same keypair for multiple sites?
- ikiris 5y ago
  What's stopping an idiot from doing so?
  - addingnumbers 5y ago
    The fact that it's a bare-bones technical demonstration and an idiot would have no wherewithal or purpose to implement it.
    - md_ 5y ago
      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. ;)
Zamicol 5y ago
It's the same for passwords. The advantage is that your private key can't be leaked on a third party website.

jmwilson 5y ago

"Much simpler than webauthn" Is it? Trying out https://webauthn.io/ 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 challenge is the current time, the signed auth message can be replayed against any other site where the user set up using the same key.

_pzht 5y ago
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.
- pornel 5y ago
  "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.
- UncleMeat 5y ago
  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.

srfilipek 5y ago

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 5y ago
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 5y ago
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 5y ago
  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.
  - 5y ago

ipnon 5y ago

This post has ironically convinced me to use WebAuthn instead.

stavros 5y ago
I really like WebAuthn, I only wish it were supported everywhere.

woodruffw 5y ago

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.

staticassertion 5y ago
Yes, this looks like it's just a worse version of passwords.
md_ 5y ago
It’s worse. It encourages the use of the same strong “password” on every website?
- 0xdeadb00f 5y ago
  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.
  - Xylakant 5y ago
    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?
    - md_ 5y ago
      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!"

yuliyp 5y ago

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.

hn_throwaway_99 5y ago
> 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.
- gruez 5y ago
  >The whole benefit of hardware token-based authentication [...] Technically it's not something limited to hardware tokens. You can conceivably do something similar with username/password authentication, as long as the credentials are sent to the browser and not the site.
- md_ 5y ago
  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 that user agents are or aren’t validating the origin (or relying party)—it’s that the same key+challenge is used for every origin. (As a result, there’s nothing for the user agent to validate, because the same signature is used for all origins!) It’s like using the same password for every website you log into. As severe understatement, this is a very, very bad protocol design, and nobody should use it.

asojfdowgh 5y ago

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

pxx 5y ago
This seems similar in concept to https://github.com/michft/ssh-mars https://github.com/michft/ssh-mars or https://github.com/wes1138/webauth-via-ssh https://github.com/wes1138/webauth-via-ssh but you could imagine that the person running the SSH server doesn't necessarily need to be the person running the website.

staticassertion 5y ago

Lots of things are easier than webauthn if you don't provide the same guarantees.

dcow 5y ago

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 <insert your language of choice>. The only thing WebAuthn needs to figure out is soft keys. 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. If whatever agent handling the soft key encrypts it at rest using device keys you’re effectively isomorphic to “key never leaves the device”. It would be nice if hardware devices supported a non-resident key mode where you could give it an encrypted key and it would decrypt the key on device memory using an on-device key and then use the decrypted key for a crypto operation (encryption or signing). Then you could get a pretty much perfectly isomorphic experience with a non-resident key.

inetknght 5y ago
> Users don't want to enroll devices they want to log in with face/touch ID. Not all users. I'm a user. I want to log in with my SSH key because it's far more secure than my face or fingerprint.
- dcow 5y ago
  Yeah sorry I should have qualified: average consumer users.
woodruffw 5y ago
> 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, a software implementation, TouchID/FaceID, or anything else. You can already use TouchID and FaceID on sites that use WebAuthn, and the UX is perfectly fine. You still have to enroll the device, but that's no different from the Face/TouchID UX in any other authentication context.

ignoramous 5y ago

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 https://news.ycombinator.com/item?id=9655245 As good as WebAuthn is, research around PAKEs is currently the most exciting to me: https://blog.cloudflare.com/research-directions-in-password-security/ https://blog.cloudflare.com/research-directions-in-password-...

MayeulC 5y ago
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.

pabs3 5y ago

This reminds me of TLS client certs.

quickthrower2 5y ago

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!

endorphine 5y ago

I was a bit disappointed that the "Advantages of this approach" section wasn't followed by a "Disadvantages of this approach".

_8j50 5y ago

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.

megous 5y ago
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.