3 ms·

Thinking about Passwords

samwillis 5y ago
Edit: Ignore below as I skimmed the article too quickly. Shouldn’t try and read something like this with screaming children in the room. - I think this proposal is a little more complicated than it needs to be, and it's adding a lot of friction to an already annoying login process. I run a site that has a registration option, people avoid it as much as possible. Personally I'm a fan of the magic login email link, super simple and reliable. Just fingerprint/cookie the device that initiated the login to ensure that the email has been clicked on the same device. Most services would be compromised my a users email becoming compromised due to "Forgotten Password" recovery systems. So a magic email login link is no less secure in my eyes.
- mimsee 5y ago
  > Just fingerprint/cookie the device that initiated the login to ensure that the email has been clicked on the same device. I usually open these on my phone since it usually comes as a push notification.
- jsnell 5y ago
  I think this wasn't about writing a login system for a new service though. It was about sharing the credentials to various third party systems, whose login systems are not controlled by the author.
  - samwillis 5y ago
    You are quite right, skimmed it too quickly.
_wldu 5y ago
I'm currently experimenting with Ed25519 signatures in place of passwords for website authentication: Git repo: https://github.com/62726164/ed25519-login https://github.com/62726164/ed25519-login Test website: https://gen.go350.com/ https://gen.go350.com/ I plan to write an Android and iOS app (someday) that has the same functionality as ed25519-login. We need to go password less, but the complexity of webauthn is too much IMO. I'm looking for feedback and appreciate any suggestions.
- Grimburger 5y ago
  TLS already has client side authentication baked in, it's just that no one really uses it or even knows it exists. Most (all?) browsers support it. https://aboutssl.org/ssl-tls-client-authentication-how-does-it-works/ https://aboutssl.org/ssl-tls-client-authentication-how-does-...
  - _wldu 5y ago
    Yes. Mutual TLS. But that involves certificates, potentially CAs, dealing with certificate expirations and other PKI formalities. Any user can generate an Ed25519 key pair, base64 encode the public part of the key and register that with websites. It's more informal than TLS certificates and totally user controlled. I do use TLS client certificates (with several APIs) but I don't consider them as password replacements (which is the goal of ed25519-login).
- dyml 5y ago
  I agree that WebAuthn is complicated (I’ve read the W3C spec more times than I care to admit). Disclaimer: I maintain an open source FIDO2 library. However WebAuthn has the might of device-, OS and browser makers behind it which improves the chances of wide adoption and “what users will expect”-rate. For those who do not want to understand all the complexity, but still leverage high security and “fingerprint / faceid” sign in on their web app we created passwordless.dev. It’s a very easy way to try out and implement webauthn in your project. Happy to help fokes get started if you’re interested! You can get your API key or run the demo on: https://passwordless.dev https://passwordless.dev
ricopags 5y ago
I appreciate the frustration, and share it. I wonder, though: Is this significantly different from how onetimesecret[0] works? 1password also has a secure sharing feature[1]. I used to use onetimesecret but find 1password to be sufficient to my needs. [0] https://onetimesecret.com/ https://onetimesecret.com/ [1] https://blog.1password.com/psst-item-sharing/ https://blog.1password.com/psst-item-sharing/
notfed 5y ago
> I run into the problem of securely granting access to services to these contractors regularly. Maybe you could elaborate on the problem statement? Passwords for what? And it seems presumed that these are services can't support token-based authorization; i.e. only support raw passwords?
davidkuennen 5y ago
I've come really to appreciate passwordless authentication [1]. [1]: https://auth0.com/docs/authenticate/passwordless/authentication-methods https://auth0.com/docs/authenticate/passwordless/authenticat...
blakesterz 5y ago
An interesting idea. Reminds me of SQRL for some reason: https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm A somewhat similar solution to the same problems? Or at least follows the same kind of thinking to a different solution perhaps.
xondono 5y ago
In terms of user experience IMO, what you’d want is something similar to how Apples “share wifi password” work but with extra features. You want to log in to x, there’s a place to put the owners email or phone number, they get (if you are previously on some “accept list”) a notification that let’s them grant or deny access. You don’t get to see any password, you just get logged in. Ideally you’d also want them to be time limited and revocable.
latchkey 5y ago
The token server seems like a ripe attack vector.

Edit: Ignore below as I skimmed the article too quickly. Shouldn’t try and read something like this with screaming children in the room. - I think this proposal is a little more complicated than it needs to be, and it's adding a lot of friction to an already annoying login process. I run a site that has a registration option, people avoid it as much as possible. Personally I'm a fan of the magic login email link, super simple and reliable. Just fingerprint/cookie the device that initiated the login to ensure that the email has been clicked on the same device. Most services would be compromised my a users email becoming compromised due to "Forgotten Password" recovery systems. So a magic email login link is no less secure in my eyes.

mimsee 5y ago
> Just fingerprint/cookie the device that initiated the login to ensure that the email has been clicked on the same device. I usually open these on my phone since it usually comes as a push notification.
jsnell 5y ago
I think this wasn't about writing a login system for a new service though. It was about sharing the credentials to various third party systems, whose login systems are not controlled by the author.
- samwillis 5y ago
  You are quite right, skimmed it too quickly.

_wldu 5y ago

I'm currently experimenting with Ed25519 signatures in place of passwords for website authentication: Git repo: https://github.com/62726164/ed25519-login https://github.com/62726164/ed25519-login Test website: https://gen.go350.com/ https://gen.go350.com/ I plan to write an Android and iOS app (someday) that has the same functionality as ed25519-login. We need to go password less, but the complexity of webauthn is too much IMO. I'm looking for feedback and appreciate any suggestions.

Grimburger 5y ago
TLS already has client side authentication baked in, it's just that no one really uses it or even knows it exists. Most (all?) browsers support it. https://aboutssl.org/ssl-tls-client-authentication-how-does-it-works/ https://aboutssl.org/ssl-tls-client-authentication-how-does-...
- _wldu 5y ago
  Yes. Mutual TLS. But that involves certificates, potentially CAs, dealing with certificate expirations and other PKI formalities. Any user can generate an Ed25519 key pair, base64 encode the public part of the key and register that with websites. It's more informal than TLS certificates and totally user controlled. I do use TLS client certificates (with several APIs) but I don't consider them as password replacements (which is the goal of ed25519-login).
dyml 5y ago
I agree that WebAuthn is complicated (I’ve read the W3C spec more times than I care to admit). Disclaimer: I maintain an open source FIDO2 library. However WebAuthn has the might of device-, OS and browser makers behind it which improves the chances of wide adoption and “what users will expect”-rate. For those who do not want to understand all the complexity, but still leverage high security and “fingerprint / faceid” sign in on their web app we created passwordless.dev. It’s a very easy way to try out and implement webauthn in your project. Happy to help fokes get started if you’re interested! You can get your API key or run the demo on: https://passwordless.dev https://passwordless.dev

ricopags 5y ago

I appreciate the frustration, and share it. I wonder, though: Is this significantly different from how onetimesecret[0] works? 1password also has a secure sharing feature[1]. I used to use onetimesecret but find 1password to be sufficient to my needs. [0] https://onetimesecret.com/ https://onetimesecret.com/ [1] https://blog.1password.com/psst-item-sharing/ https://blog.1password.com/psst-item-sharing/

notfed 5y ago

> I run into the problem of securely granting access to services to these contractors regularly. Maybe you could elaborate on the problem statement? Passwords for what? And it seems presumed that these are services can't support token-based authorization; i.e. only support raw passwords?

davidkuennen 5y ago

I've come really to appreciate passwordless authentication [1]. [1]: https://auth0.com/docs/authenticate/passwordless/authentication-methods https://auth0.com/docs/authenticate/passwordless/authenticat...

blakesterz 5y ago

An interesting idea. Reminds me of SQRL for some reason: https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm A somewhat similar solution to the same problems? Or at least follows the same kind of thinking to a different solution perhaps.

xondono 5y ago

In terms of user experience IMO, what you’d want is something similar to how Apples “share wifi password” work but with extra features. You want to log in to x, there’s a place to put the owners email or phone number, they get (if you are previously on some “accept list”) a notification that let’s them grant or deny access. You don’t get to see any password, you just get logged in. Ideally you’d also want them to be time limited and revocable.

latchkey 5y ago

The token server seems like a ripe attack vector.