6 ms·

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 s

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

sedatk 6y ago
> which proves that this is possible. How does it prove that?
- anderslemke 6y ago
  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 6y ago
    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 6y ago
      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.
deleted 6y ago
[deleted]
jiveturkey 6y ago
this uses OIDC. it’s a non starter, for reasons unrelated to the part you are “solving” here.
- jniedrauer 6y ago
  Can you be more specific?
  - gravypod 6y ago
    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.
- anderslemke 6y ago
  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.
sudoit 6y ago
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 6y ago
  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
Ajedi32 6y ago
There's been a W3C standard that meets all those requirements for a couple years now: https://www.w3.org/TR/webauthn/ 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 6y ago
  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.
kogir 6y ago
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 6y ago
  That sounds painful in so many ways...
mawise 6y ago
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/ https://indieauth.net/
- F3nd0 6y ago
  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/ https://reclaim.gnunet.org/ 2. https://gnunet.org/en/gns.html https://gnunet.org/en/gns.html
  - theamk 6y ago
    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 6y ago
      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.
zajio1am 6y ago
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 6y ago
  > 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 6y ago
    >×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 6y ago
      > 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.
TedDoesntTalk 6y ago
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 6y ago
  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.
glokk 6y ago
There's another privacy-focused SSO solution from SimpleLogin that creates a different email address for each relying party.
- anderslemke 6y ago
  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.
dkdk8283 6y ago
I see it as a stepping stone for global “real id”. In this case centralization is a feature, not a bug.
- anderslemke 6y ago
  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.

sedatk 6y ago

> which proves that this is possible. How does it prove that?

anderslemke 6y ago
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 6y ago
  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 6y ago
    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.

deleted 6y ago

[deleted]

jiveturkey 6y ago

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

jniedrauer 6y ago
Can you be more specific?
- gravypod 6y ago
  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.
anderslemke 6y ago
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.

sudoit 6y ago

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 6y ago
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

Ajedi32 6y ago

There's been a W3C standard that meets all those requirements for a couple years now: https://www.w3.org/TR/webauthn/ 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 6y ago
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.

kogir 6y ago

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 6y ago
That sounds painful in so many ways...

mawise 6y ago

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/ https://indieauth.net/

F3nd0 6y ago
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/ https://reclaim.gnunet.org/ 2. https://gnunet.org/en/gns.html https://gnunet.org/en/gns.html
- theamk 6y ago
  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 6y ago
    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.

zajio1am 6y ago

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 6y ago
> 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 6y ago
  >×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 6y ago
    > 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.

TedDoesntTalk 6y ago

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

glokk 6y ago

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

anderslemke 6y ago
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.

dkdk8283 6y ago

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

anderslemke 6y ago
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.