[anderslemke]

The risk of getting your account locked is just one of the reasons you shouldn't use Google (and the like) to sign in.

But how did we end up in this horrible state of authentication? Why don't we have something as easy to use as the DNS, but for authentication?

Imagine what authentication would look like, if we all started running is the same direction, instead of implementing our own authentication again and again. If we had something open source, that would allow you to sign in to all the sites you use, while completely protecting your privacy, so none of them know who you are.

This dream can come true. Technically at least. I've taken the the first baby steps with https://promiseauthentication.org which proves that this is possible.

But, for this to become a reality, we really need to start running in the same direction. A collective movement towards a sane, privacy-first Single Sign-On provider that's easy to use for everybody.

[mawise]

It's a step in the right direction, but it's still centralized. A lot of the work done by the Indie Web community around IndieAuth[1] is really attractive. Your identity is your domain, and you can change how your domain says you're allowed to authenticate. Now you can even use sign-in with google without getting locked out should you loose your google account.

Aligns really well with using your own domain for email instead of gmail.

[1] https://indieauth.net/

[quicklime]

I hadn't heard of either Promise or IndieAuth before reading this thread, so apologies if this is a dumb question. But one of the benefits of Promise is that it's pseudonymous:

> You will get a unique identity pr. service you use. This ensures that relying parties have no way to profile you across services.

For me, this is actually the biggest reason that I stopped using social sign-ins. It's not that Google might disable my account one day; it's more that I don't want Google or Facebook tracking me.

How does a decentralized system handle this? If my identity is my domain, doesn't that mean that all these websites now have a unique id which they can use to join together all their separate pieces of data about me?

[mawise]

You're right, all the websites could band together to coordinate and share that the same person logged into each site. They do this today with email addresses and phone numbers explicitly (and implicitly with "advertising IDs" and the like). The Facebook "like" button and Google analytics are both tools to make it easier to track you around the web. Getting away from being able to track you around the web is going to take a lot more than just an anonymous ID as your login credential.

That said, the unique identity is still valuable--Apple offers this with their third party sign in[1]. Practically, if everyone was using self-hosted identity, then the tools would probably make it easy for you to create and track your own new identities for each service you use. This isn't build into something like IndieAuth today, but with the right DNS settings you could have arbitrary subdomains return the same authentication options and act as easy-to-use "sub identities".

[1]: https://support.apple.com/en-us/HT210425

[anderslemke]

Being pseudonymous is one of the main selling points of Promise.

Only by being pseudonymous can it provide the level of privacy that should be expected from the global authentication infrastructure that Promise wants to be.

[account42]

Does Promise get to know which sites you sign in to?

[anderslemke]

Yes. Promise keeps a map of your sites and IDs.

[s_gourichon]

Isn't that a problem, like "let's get rid of Google and all the evildoers because they know too much about us" then "oh we realize we created another one which knows too much about us"?

[F3nd0]

There’s also re:claimID¹, which should be fully distributed and work on top of GNS², but it’s still very much a work in progress.

1. https://reclaim.gnunet.org/ 2. https://gnunet.org/en/gns.html

[theamk]

First promotion point:

> Self-sovereign You manage your identities and attributes locally on your computer. No need to trust a third party service with your data.

Why do people assume that is a good thing? I do cybersecurity at work (among other things) and it takes a lot of effort to keep things both available and secure. My home PC, not to mention PCs of my friends, are never going to be as secure.

A system which has a chance will have to be federated, not local-only.

[Osiris]

I work in crypto and we sell a hardware device to keep your seed phrase secure and the physical device is required to sign transactions.

But then you should listen to the advice we're given if we use one for personal use.

1. buy two devices

2. Generate a phrase on one then import to the other

3. Put the second one in a safety deposit box in another city or state, or a safe with a family member also out of the city or state.

4. Keep a copy of the phrase on steel seed phrase tool (Steely, etc)

5. Mount the steel seed phrase backup inside of a wall of your house and plaster and paint over it.

6. If your phrase ever gets seen by any electronic means, it's compromised and the process must be redone (note that importing uses a randomly shuffled alphabet on the device to make MITM or keylogging attacks unusable).

So... Security is hard. We should build systems that make it easy. There should be ways to recover from backups of a service goes offline, but we can't expect everyone to make good decisions.

Not to mention having passwords synced between devices and available on demand is really a requirement of you use random passwords for every site and need to log into something (heaven forbid) on someone else's device.

[TedDoesntTalk]

> [effective and meaningful] Security is hard. We should build systems that make it easy

These are in direct conflict with each other.

[bsder]

Not necessarily.

What's your threat?

Most people are not trying to stop a determined attacker. Most people just want random people to not get be able to get into their stuff--same as a physical lock.

They carry a physical key on their person. It's not too much to ask them to carry a "digital" key on their key ring.

The problem is that most "digital" keys are a pain in the ass:

1) Mostly because everybody wants to "centralize" authentication so that they can charge you and administrate you.

2) Secondarily because there is no good solution for talking to the key on your person. NFC sucks. USB requires that I plug my key in. WiFi requires that the device be able to hit your network. BLE has no access from web pages.

BLE is probably the best choice, but there is no real money in making it work.

[anderslemke]

I'm a bit divided on whether or not the "centralized" thing is actually a problem Promise should tackle.

On one hand, I want to tell you that Promise is only centralized by default. Which is good for people that doesn't understand what a OpenID/IndieAuth Provider is. But as Promise is open source and the protocol caters for it, it is possible to have Promise redirect authentication requests to your own instance. Which then redirects you back to the relying party you want to sign in to. So it is possible to decentralize if that is what you want

On the other hand, I'm not sure it's a good idea to do it. Centralizing gives a lot of benefits. User experienc being one, but also being able to roll out eg. security updates quickly. But sure, centralization also creates problems.

But until now, I have a feeling that the problems with centralization, can be solved by other measures than going decentralized. Eg. being a non-profit organisation owned by the relying parties. This would guard against a lot of the problems with being centralized.

And I'm still to encounter a decentralized solution with a reasonable user experience for most people. OpenID, IndieAuth, SQRL, re:claimID, I'm looking at you. Sorry.

[mawise]

You're right that the user experience is a huge blocker, but I think that's something we as authors of tools can improve on. For example, there's a Wordpress plugin that lets your Wordpress site act as an IndieAuth identity[1]. That makes it pretty usable from and end-user perspective.

The challenge with centralized is that it is a single point of failure. The original post was more focused on "If you get locked out of google, you get locked out of everything". In that vein if promise gets hacked/bought/abandoned/changes it's business model etc.. then you lose all your accounts. The anonymous nature of it is great, but this is something Apple already offers with their sign-in with apple which is already widely supported and with the proxy-email solution you can still be contacted by the sites you're signing up with.

I got interested in IndieAuth because of a project of mine[2], trying to make it really easy for everyone to self-host their facebook/twitter equivalent with direct control over who has access. This runs into the problem with wide adoption where you have a separate credential for each of your friends' blogs. With IndieAuth built into the self-hosted platform, then your own self-hosted site becomes the one credential you can use on all your friends' sites. Self-hosted distributed identity for privacy AND ease-of-use.

[1] https://wordpress.org/plugins/indieauth/ [2] You can find the link in other comments I've made on HN

[anderslemke]

I'm really happy that you're willing to take this discussion with me.

I totally understand what makes IndieAuth is a good solution. And it seems really easy. For me. But I have no idea how I would go about explaining it to, let's say, my mom.

Apple is offering something very similar to what Promise does. The difference is that Apple is a commercial corporation. Which means they're in the game to make money. Promise will be in the game to make authentication easy, secure and private.

In many ways I compare the goal of Promise, with the goal of DNS. Take a commodity and make it available globally in a reliable way. Yes, it will be a single point of failure. So the job of Promise will in large be, to keep the platform secure and reliable.

[mawise]

The mom-test is a good one, I'll have to think more about it. The truth is the advantages and disadvantages of various authentication systems are subtle, and hard for a lot of technical people to understand, much less care about.

Apple is a commercial corporation, and one of the biggest (by market cap) companies in the world. That gives me confidence that they'll be around for a long time, have sufficient resources to invest in security and reliability, and they have a well-established reputation for a focus on security. They do other things I don't like[1], but I think this is one area where they're setting really good precedent.

In addition, it's going to be difficult getting any sites (outside of maybe the crypto/grey-market) to adopt an auth system that doesn't let them contact their users. This is also I think a big failing of IndieAuth.

[1]:https://sneak.berlin/20201112/your-computer-isnt-yours/

[anderslemke]

Promise is basically challenging the assumption that authentication has anything to do with both personal identity and being able to contact a user.

If a site needs to contact the user, it's reasonable to ask for eg. an email. But now the intent of asking for an email has to be crystal clear, which makes you and them more aware of what data you are actually giving them.

Apple sure is doing some good stuff with their authentication solution and their efforts to help people with healthier passwords habits. I'm still not too fond of having such fundamental infrastructure owned by a private company. Would you be comfortable handing over DNS to Apple?

[kogir]

I was my own OpenID Provider for a while, but quit because nobody supports it anymore. It was great for power users but super confusing for laypeople.

[anderslemke]

That sounds painful in so many ways...

[Ajedi32]

There's been a W3C standard that meets all those requirements for a couple years now: https://www.w3.org/TR/webauthn/

Only problem is there aren't any password managers that implement it, so it's not actually practical to use as a primary authentication factor yet.

[anderslemke]

WebAuthn is great! I don't see any reason why Promise shouldn't implement it.

I see it this way, that Promise makes it possible for all its relying parties leverage WebAuthn by implementing it once, so they don't have to.

[TedDoesntTalk]

There is so much fragmentation in authorization and authentication that it is hard to see how we can “run in the same direction”. Facebook, google, etc have zero incentive to change anything.

[anderslemke]

Yes. The fragmentation is part of what makes authentication a horrible experience.

But most of all, what I'm missing is at least one good option on the sign-in screen. And using a password manager is not it.

[zajio1am]

There is TLS client authentication, unfortunately it never catched on, probably due to not good and uniform UX in browsers. Imagine if web-browsers have automatically generated password-protected self-signed certificates that could be used to authenticate to web services without need of any third-party.

[u801e]

> Imagine if web-browsers have automatically generated password-protected self-signed certificates that could be used to authenticate to web services without need of any third-party.

What should be done when creating a new account is that, in addition to the username and password, the website should allow for uploading a certificate signing request. The web browser should then allow the user to create one and upload it. The website should then return the signed certificate to the client and the browser can then store it to use during subsequent connections.

Doing something like this would allow for two factor authentication without the half-baked solutions like sms or email based 2fa.

[GordonS]

>×The web browser should then allow the user to create one and upload it

Your average user is not going to open a command prompt and dig into Openssl. There are (or were, I haven't used them for a decade) browser-specific APIs for generating private keys locally, but they were very flakey, and the whole UX was very confusing for users.

And after this, the user can only sign in on the machine in which the key was created. Your average user will not have a clue how to move certificates and keys around between machines.

I have direct experience with this. Back in 2008 I led a team building an extranet site, and we used X.509 client certificate authentication. We had to build our own tooling for management of the PKI, which was no small task. But ultimately it was key creation and certificate distribution that were the biggest problem - our users absolutely hated the signup process, as well as the fact that they couldn't later signin on another machine.

[u801e]

> Your average user is not going to open a command prompt and dig into Openssl.

That's why I said that the browser should provide that feature.

> There are (or were, I haven't used them for a decade) browser-specific APIs for generating private keys locally, but they were very flakey, and the whole UX was very confusing for users.

That's a UX issue that can be solved if the time was put into it

> And after this, the user can only sign in on the machine in which the key was created. Your average user will not have a clue how to move certificates and keys around between machines.

They shouldn't be moving/sharing keys between machines at all. What could be done is to implement a mechanism to associate an additional device with the account. Perhaps something like sending a CSR from the new device and then using the first device to confirm that it's a legitimate request.

[thw0rted]

> something like sending a CSR from the new device and then using the first device to confirm that it's a legitimate request

So I can only sign into my account from any new machine if I have access to a previously-signed-in device? What happens if my last login session expires? At that point, I have to sign in with a password, and now I'm back to all the terrible things about managing 500 passwords.

Federated identity / SSO through a trusted provider makes so much more sense, the standards are open and there are dozens of implementations available. Nobody needs to reinvent the wheel, we don't need a 15th standard. You just have to sign in with a provider that you trust not to lock you out for no reason, in a way that gives you no recourse (unless you can get your story on the front page of HN). Obviously that provider is not Google.

[u801e]

> So I can only sign into my account from any new machine if I have access to a previously-signed-in device?

The scenario I'm envisioning is that one creates an account on a website like HN, but with the additional step of generating a CSR, sending it, and receiving a certificate to store locally (with the browser handling the generation of the CSR and storing the resulting certificate with a standard and easy to understand UX workflow).

Once signed into the account, the website could prompt the user to add additional devices if they so wish (e.g., I created the account and signed in on my laptop, now I'll add my smartphone as a trusted device). This step could be done now, or sometime in the future.

If the prompt encourages users to do so right after creating the account, it's likely that they'll have access to the original device to confirm additional CSRs. Even if they choose not to do so right away, I don't think it's an unreasonable requirement to have access to the original device.

> What happens if my last login session expires? At that point, I have to sign in with a password, and now I'm back to all the terrible things about managing 500 passwords.

If the situation was that websites used 2FA via having the username/password as one factor and client-side TLS as the second factor, then password reuse wouldn't be an issue. Even if someone were to guess the username/password combination, the most they could do is send junk CSRs to try to add their device, which can then get rejected or not acknowledged by the original account holder.

> Federated identity / SSO through a trusted provider makes so much more sense

Perhaps, but based on what I've seen for general services out there, they just use either Google and/or Facebook as the trusted provider. I'm not sure how that situation came about, because it was pretty easy to create multiple accounts on those services without having to provide any basic identifying information (which essentially is the antithesis of what should be considered a trusted provider).

SSL/TLS is a standard that has been around for a long time, and given the ubiquitous use of server-side TLS, I don't see why it would be considered re-inventing the wheel to use the client side part of it. With nginx, you could set a HTTP header with proxy_set_header based on the value of the $ssl_client_verify variable value. Then the application could direct the user to the login page. If the client-cert is valid, then allow them to log in normally. If not, then direct them to log in, send a CSR, and go back to a valid device to confirm that CSR.

> You just have to sign in with a provider that you trust not to lock you out for no reason, in a way that gives you no recourse (unless you can get your story on the front page of HN). Obviously that provider is not Google.

Personally, I think we shouldn't have to involve third party providers in the authentication process. One reason is what you've already mentioned about getting locked out of the account. The second is if that account is compromised. With TLS, you don't need a third party involved in the process at all for the client side.

I just find it disappointing that I'm essentially forced to use email or SMS based 2FA where, arguably, those are less secure compared to having a strong password on the original service. By less secure, I mean that those factors could be compromised in a way to access my account that completely bypasses my strong password. It's the same with requiring security questions and allowing access to the account via a well known answer to one or more of those questions.

[sedatk]

> which proves that this is possible.

How does it prove that?

[anderslemke]

I've built Promise, to prove (to myself at least), that it would be technically possible to build authentication infrastructure, that can be used across sites, without having to store any data unencrypted, and furthermore, not storing any personal data at all.

And it works.

It's a bold choice of words, I acknowledge that. And the proof is only as strong as my abilities to write software.

This is yet another reason why Promise needs a movement behind it. To strengthen the proof. To strengthen security.

[sedatk]

I understand, but don't you still have the capability to ban a domain/user? How is it different than Google in the context of the post?

[anderslemke]

Being a non-profit, collectively owned service, which Promise is, will make it difficult to ban users and relying parties.

Just like the DNS can block users, Promise can ban users and relying parties.

This is not something Promise should take lightly, but the fact that almost everyone has a say in Promise, unlike Google, where almost no one has a say, makes me full of hope that this can be solved in a transparent way.

[sudoit]

Cool demo. I couldn’t figure out how to make an account though.

I think this would need serious widespread adoption until we saw benefits too. And you’d need some big names...like Google. Which probably will never happen.

[anderslemke]

Ok, you're not the first to say that...

I hate it, when I type my email and password (correct, that is), and get an error saying "You already have an account. You need to sign in". OK. But would you please just sign me in then. Everything you need is there.

So I chose to make it one. This might be more confusing than anything else... And I might be missing some other point for this to make more sense...

And yes, let's get that widespread adoption

[dkdk8283]

I see it as a stepping stone for global “real id”. In this case centralization is a feature, not a bug.

[anderslemke]

That is an interesting point.

Internet identity could maybe be a layered thing where one layer takes care of authentication, which is where Promise lives. The next layer could handle information like name and email. And finally a layer that handles your verified identity by an authority. That last layer is where the danish NemID fits in.

[glokk]

There's another privacy-focused SSO solution from SimpleLogin that creates a different email address for each relying party.

[anderslemke]

I didn't know SimpleLogin. It seems really nice. Kind of what Apple does with their "Sign In with Apple".

It's not exactly a SSO, though.

[jiveturkey]

this uses OIDC. it’s a non starter, for reasons unrelated to the part you are “solving” here.

[anderslemke]

I would love to understand the reasoning here. Sincerely.

What makes OIDC a "non starter"?

I see OIDC as an implementation detail, and have no strong opinions about it.

[jniedrauer]

Can you be more specific?

[gravypod]

For a smaller company, that doesn't have the ability to dedicate a team of people to authn and authz, OIDC/OAuth/SAML/etc are all extremely complicated tools that take a lot of experience to even begin to understand the terminology. Ask your average engineer to implement logins for an API they'll be able to do it. Ask your average engineer to implement current SSO-like integrations for even the most standard of use cases (website logins) and it's a huge pain. Drift ever so slightly off the beaten path (IoT devices for example) and you're in for a "fun" time.