Thinking about Passwords | Hacker News Reader

Thinking about Passwords

herman.bearblog.dev

I'm currently experimenting with Ed25519 signatures in place of passwords for website authentication:

Git repo: https://github.com/62726164/ed25519-login

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.

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

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

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

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/ [1] https://blog.1password.com/psst-item-sharing/

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.

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.

You are quite right, skimmed it too quickly.

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

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.

An interesting idea.

Reminds me of SQRL for some reason: 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.

I've come really to appreciate passwordless authentication [1].

[1]: https://auth0.com/docs/authenticate/passwordless/authenticat...

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

The token server seems like a ripe attack vector.

Reply on news.ycombinator.com