-
Hey, seems like a nice idea, but how is it different from OpenID?
-
-
-
-
That would be a great name… I’ve thought about it when I’ve been working on APIs or languages or tools for languages: what is the user experience for a developer who is using this thing? What can I do to make this thing more pleasant to use? Languages like Elm have great “UX”, whereas tools like Burp & ZAP have terrible UX for analysts. DX is a neat condensation of that…
-
-
-
-
-
In some ways, you can think of Portier acting as an adapter in front of other OAuth / OpenID providers, so you integrate with Portier once, and get consistent support for other providers for free. More in the design document.
The other big difference is that Portier asks users for an email address, and provides a fallback which ensures that Portier works for all email addresses. This is a huge improvement over classic OpenID, which used opaque URLs for identities, and OpenID Connect, which effectively requires every website to pre-register with, whitelist, and display custom buttons for specific OAuth providers.
Portier is just email in, auth out, using whatever protocol is most appropriate for that email domain. Way more humane for users.
Otherwise, most of the virtues of OpenID should carry through. There’s deeper discussion of how Portier compares to Persona in OtherProjects.md.
-
-
Congratulations, guys, this is big news.
I think this is interesting… until people start attacking DNS or the like. I don’t even mean in terms of Mirai or the like… I mean things like what happened to Kenneth Reitz. Those sorts of attacks aren’t even theoretical, or even necessarily intentional; I had a large financial services client do an entire rebranding effort, walk through the entire setup of creating new brand data, &c. … only to completely forget to register the domain name. They were already handing out email addresses to someone else’s domain.
tl;dr: I think it’s a neat idea, and I’d love to see where you go with it, but as a security person, these sorts of things scare the tar out of me.
I hear this a lot, but what people don’t realize is that this is no less secure than what we’re doing now. If someone hijacks your email provider’s DNS, you’ve already lost, no matter how secure your password.
I guess the problem is that centralized authentication this direct doesn’t sit well with people, whereas the existence of the “reset your password by email” link is easier to ignore, even though it’s exactly the same as something like Portier.
oh I agree it’s not any less secure; we argue about password reset links all the time at work, for example. It has all the same security risks as password reset links, or what slack is doing with “magic links” to login.
It’s just that I sit on the side of the fence that password reset links are terrible too, depending on your risk level. I think for most things this is an intriguing fix to a problem and I’d like to see it work. I think the difference is that I work in government and high-finance and email is considered at best a necessary evil.
Again, super interesting idea, and I’m curious to see where you go, but I probably won’t see it in my domain for a while yet (if ever).
I am not a Slack engineer, but unlike generic password reset links, the Slack “magic links” does not need to have the same vulnerability as Password Reset Links (whether or not it’s vulnerable in practice is a separate issue, as I’ve mentioned I don’t work for Slack…).
Here’s the secure scenario:
If our primary attack vector is email interception (between steps 1 and 2), then we can guarantee that the magic link alone will not authenticate them on any device other than the originating device because the imposter lacks the original token to close the loop and sign the final request (step 3).