7 ms·

Portier – An email-based, passwordless authentication service

206 points by samps 10y ago

awinter-py 10y ago
Real question here is 'why isn't auth built in to the browser'. Lack of browser support is the reason oauth is so complicated (it relies on HTTP redirect to pass information around). Imagine a web experience sans cookies and sans JS. If you take into account the economics of content, it can only happen with browser-mediated login.
- ejcx 10y ago
  It is* Credential Management[1] is newly ratified (or will be ratified soon I lose track at this point. Mike West works fast). Either way, the api is exposed to chrome. The best I can understand is that Google and Apple both want to store your passwords in the browser/keyring, and sync them between your devices. Apple has begun "suggesting" passwords in Safari that are fairly strong. It's scary to think about, but "browser" is already the most used "password manager". It just is not full featured yet. [1] https://w3c.github.io/webappsec-credential-management/ https://w3c.github.io/webappsec-credential-management/ * you are using chrome
- aethertron 10y ago
  Could it be done in a non-spoofable, decentralised way? Xanadu is/was specified to include user authentication. No idea about the implementation there.
  - jamesgeck0 10y ago
    Yes. Mozilla Persona was explicitly designed with the intent of having auth as a feature in every browser.
- deleted 10y ago
  [deleted]
- pmontra 10y ago
  Basically you're asking for an authentication standard. Some de facto standards are completely client side. Browsers embed at least the "fill form/remember password" authentication method. It's not a standard and some people use it. Some people use an external password manager instead (I do, keepassx). Some password managers come with addons for the major browsers. Other people don't use anything and try to remember passwords, sorry for them. Maybe your question was why don't browsers embed oauth? About the sans cookies experience, with oauth or without it, there should be a standard way for browsers to send authentication info in the request. I don't see another way, but I might be wrong. Basic auth is a way, cookies are another. Both are ok only with https. What do you suggest instead?
- callahad 10y ago
  In the long run, authentication should be baked into browsers, and it seems like FIDO U2F is making decent strides in that arena. For right now, I think Portier hits a sweet spot for smaller sites without a lot of time or energy to put into building out bespoke authentication integrations.
- tomjen3 10y ago
  It is, and has been since god knows when: client certificates. Better than passwords because they can't be phised, doesn't require an email, doesn't require trusting any third-party service. Unfortunately they are also very difficult to understand for even normal geeks and so basically no site use them.
  - drdaeman 10y ago
    It's not hard to understand ("you have the key, in a form of file or a hardware token, use it to open your account" is something average grandma can grok - no harder than passwords), but current UI and UX are terrible. Then it's chicken-and-egg problem: no one uses certificates because they're unuseable, and no one works on their usability because no one uses them.
- closeparen 10y ago
  Client cert support has been built into the browser for a long time. One problem is that you basically have to build out non-cert authentication to give people certs to install. That, and there's little to no mutual trust, so every institution needs to issue and manage its own certs.
  - bradleyjg 10y ago
    If the client certificate distribution problem was a one-time per site thing it wouldn't be so bad. The issue is that people want to be able to use multiple browsers on multiple devices, and some of those browsers are in use by multiple people.
    - drdaeman 10y ago
      In theory, it's well possible to sync keystores (just like browsers sync passwords), or issue multiple certificates for a single account. There are a lot of options and scenarios well possible (no single size fits all, of course) In practice, anything related to client certificates in browsers is not usable.
      - bradleyjg 10y ago
        If you are authenticating all the time to a sync server or a certificate granting server than that ends up being the real login process.
        drdaeman 10y ago
        Yes, it is a login process and there has to be one somewhere under the hood. Whatever the scheme is - at some point, one has to authenticate. The trick is, you set it up once and then your user agent does it for you, so all you have to do is set up sync (or any other option) once then never bother but just hit the "okay, log me in here" buttons, optionally, choosing an identity (certificate) if you have many.
- nickpsecurity 10y ago
  We tried: https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... http://srp.stanford.edu/ http://srp.stanford.edu/ Just not getting adoption it needs IIRC. Could be other explanation.
- kruhft 10y ago
  Auth is built into the browser[1], it's just ugly (popups) and nobody uses it. [1] HTTP Basic Auth
  - WorldMaker 10y ago
    Nobody uses it because: 1) HTTP Basic Auth sends passwords over plaintext. (Digest Auth at least hashes passwords, but isn't a huge security win either.) 2) Basic Auth still requires user management and if you are going to build a user management database you might as well build a login flow in HTML instead of basic auth (not just because basic auth is ugly but because you can own that login flow and provide handy things like password recovery which basic auth doesn't support). As pointed out elsewhere, HTTPS Client Certificates are a much better option baked into every browser, but we've never figured out the UX to make it convenient for the average user.
    - zimpenfish 10y ago
      As a counterpoint, https://www.rdegges.com/2015/why-i-love-basic-auth/ https://www.rdegges.com/2015/why-i-love-basic-auth/
callahad 10y ago
Hi! A few of us have been hacking on this scaled-down, spiritual successor to Persona. The core idea is that you treat this (self-hostable!) microservice like a black box: email address goes in, validated proof of identity comes out. No passwords, and no secrets to store in your application’s database. The service itself is also effectively stateless: aside from caching, the longest lived key in Redis has a TTL of 15 minutes, and no other datastore is required. So it should scale pretty reasonably, and be easy enough to administer for hobbyists. Behind the scenes, it works similarly to a password reset or passwordless login workflow, but with progressive enhancement so that, e.g., Gmail users go through Google Sign-In instead of having to check their email.
- plttn 10y ago
  >Behind the scenes, it works similarly to a password reset or passwordless login workflow, but with progressive enhancement so that, e.g., Gmail users go through Google Sign-In instead of having to check their email. I mean there's really nothing you can do about it, but it doesn't handle Google Apps / G Suite / whatever today's flavor of white-label Google services is. If I use my email which is a Google Apps account, I don't get the Google Sign-In enhancement, I get an email.
  - callahad 10y ago
    We discussed this in https://github.com/portier/portier-broker/issues/44 https://github.com/portier/portier-broker/issues/44, and unfortunately don't think there's a good way to blanket-enable support for G Suite domains. :( I'd really love to make this possible in the near future. Maybe an opt-in flag? Or finishing up our federated protocol and building a tiny service that bridges between that and G-Suite? Suggestions / feedback into that bug would be really helpful.
    - tscs37 10y ago
      A possible solution would be a DNS TXT entry (some with custom mail domains will have some sort of access to their DNS), which Portier could look up and use to determine if the service supports some form of OAuth. Alternatively, if DNS is not applicable, users could use filters and autoresponders to send back an automatic response with some code. In theory that would basically mean "Portier sends Login Mail" -> "Login Mail gets bounced via filter with additional code" -> "Portier constructs OAuth Link" -> "Portier sends OAuth back"
SimeVidas 10y ago
Note that Mozilla Persona did not support passwordless authentication. Specifically, you would still need to create a Persona password if you didn’t use a Gmail/Yahoo email address. I’ve tested this service with one of those 10-minute emails and it seems to work without any passwords, so true passwordless authentication.
- callahad 10y ago
  Yep! Requiring a separate account for Persona was, in hindsight, misguided. I've written a bit about what Persona got right and wrong, and how we* plan for Portier to be different, at https://github.com/portier/portier.github.io/blob/master/OtherProjects.md#portier-compared-to-persona https://github.com/portier/portier.github.io/blob/master/Oth... *Though Mozilla supported my work on this, Portier is an independent side project with significant code contributions from folks outside Mozilla.
overcast 10y ago
I dream of the day all logins are just simple tokens. Either sent through email, or SMS. So sick of passwords. I've used other Passwordless libraries on a few projects, and it's almost cathartic.
- StavrosK 10y ago
  The problem with that is that it breaks a user's flow too much :/ It's a good fallback, and it has many benefits, but having to switch contexts to the mail client and wait for an email is too cumbersome for the user (although it's not too bad when paired with a long-lived session). That's why Portier supports other auth providers, so you can have the best of both worlds.
  - overcast 10y ago
    Yes, and thus the reason it hasn't caught on. It's such a better idea than 75% of the passwords being Winter2016 though.
    - StavrosK 10y ago
      Agreed on both counts. Given the imminent Persona shutdown, and until I can move it to Portier, I've implemented it on Pastery as a stopgap: https://www.pastery.net/login/ https://www.pastery.net/login/ I think it works quite well (the session lasts until you log out).
      - overcast 10y ago
        Did similar at Link Packets, http://linkpackets.com/ http://linkpackets.com/ - more of a proof of concept / handy thing project.
  - Sir_Substance 10y ago
    >The problem with that is that it breaks a user's flow too much :/ Unironically and without rancor, would you say it breaks a users flow more or less than having to go fire up their password manager and find the service from dozens of entries? The number of services we use daily is increasing, and they just keep getting hacked. The idea of actually memorizing your password is rapidly becoming impractical. Most people these days who understand password security have either developed a personal algorithm for deriving passwords, or use a password manager for literally everything. I'm super glad someone has done this, because it means I don't have to get off my arse and do it, and lord knows I love laziness. Generally speaking, for websites that I log into less than once a month, I reset my password every time I log into them, and set it to a random and long keyboard smashing every time I do so. This is the same workflow, but without having to use notepad to stage the new "password" for entry into the confirmation field.
fiatjaf 10y ago
Are there any free public servers we can use for side-projects?
- callahad 10y ago
  We're literally running this on a hobby-tier Heroku dyno, with free-level redis and smtp services and doing fine at the tens-of-requests-per-minute rate. So you should be able to host your own! :) Once we implement https://github.com/portier/portier-broker/issues/88 https://github.com/portier/portier-broker/issues/88, it'll even be a 2-click process to get going. We do intend to keep https://broker.portier.io https://broker.portier.io online as a public service / reference implementation, but we don't have anyone on call or anything if it falls over. On the upside, the Broker is written in Rust, so it shouldn't segfault all that often. ;)
fiatjaf 10y ago
Is it possible to create an email-like service that doesn't actually handle email, but only serves as an identity endpoint to be used with Portier? Like, say, I create an account that reads "me@fiatjaf.com" and implement something on my fiatjaf.com server so that I can use it to login using Portier?
- StavrosK 10y ago
  Yes, it's an OIDC-compatible flow, so if fiatjaf.com implements an OIDC provider that will authenticate "me", you should be good.
- callahad 10y ago
  It will be! We're not sure what the eventual protocol will look like, but it'll probably start with webfinger, which can then point to whatever authentication gateway you want. We only need SMTP as the base case in the chain of strategies: https://github.com/portier/portier.github.io/blob/master/Design.md https://github.com/portier/portier.github.io/blob/master/Des...
  - fourbnine 10y ago
    At the risk of stating the obvious choosing webfinger implicitly excludes anyone who does not or can not control their website sufficiently to implement webfinger. (ie: hosted webservices similar to Tumblr et al)
    - fiatjaf 10y ago
      That's perfect. If you do not own the domain you shouldn't be able to use the domain like that.
      - fourbnine 10y ago
        Owning the domain is not the same thing as fully controlling the web service. My use of Tumblr as an example rather than simply stating hosted-CMS has probably misconstrued my point. (I use Tumblr with my own domain and forget that it is primarily not used that way.)
chaz6 10y ago
This sounds an awful lot like OpenID (2). What makes it different? My OpenID login (aka XRI i-name) is "=chris.hills" and works on sites that support it.
- callahad 10y ago
  There's a little more discussion of that over on Lobsters: https://lobste.rs/s/fkosun/ https://lobste.rs/s/fkosun/. The TL;DR is that URIs just didn't work for the mass public. You had to supplement the login form with a NASCAR-esque wall of logos, which was awful for different reasons. Thus, Portier, and Persona before it, chose to identify users by email addresses. I talk a little bit about that at 9:05 in my PyCon 2013 talk on Persona: https://www.youtube.com/watch?v=nJff23UdNAI#t=9m05 https://www.youtube.com/watch?v=nJff23UdNAI#t=9m05
callahad 10y ago
Postmark just dropped our outbound email for high bounce rates. Falling back to SendGrid :/ Try again in 5 minutes. Edit: Ask HN: Any suggestions for solving this? Hitting the frontpage means people are spamming the login form with bogus addresses like a@a.com that bounce and cause trouble for us and the ESPs. Not ideal, but I'm not sure how to solve this for a small scale side-project. Discussion in https://github.com/portier/portier-broker/issues/96 https://github.com/portier/portier-broker/issues/96
- danieltillett 10y ago
  I think you have just discovered the fundamental flaw of your approach. My only suggestion is send the first email from your own server and if this does not bounce then send again from postmark. I used to use a telnet based approach to check if the account exists, but most servers these day don't respond with the correct error response if an account does not exist.
  - callahad 10y ago
    I'm not sure it's a fundamental flaw: it's exactly identical to sending a confirmation email when a user signs up for a website, which is considered a best practice on the Web. If that works well enough for the Web at large, it should work here, too. As far as I can tell, the trick is building up that initial reputation and doing as much mitigation as possible up front: checking for MX records, rate limiting, soft-failing with CAPTCHAs for things that look suspicious, etc. I know what I'll be hacking on for the rest of the week. :)
    - danieltillett 10y ago
      I should have phrased this differently - it is the fundamental flaw of all email based authentication systems. Your approach is currently a bit more prone to problems since you are one nasty script away from being bounced out of existence. Yes you need to protect the log in page by rate limiting, Captcha, looking up mx records, etc. One approach I have thought would be good to use is a rainbow table like approach. Most people are not very imaginative about the fake email accounts they use.
woodcut 10y ago
I tried purely email based authentication in the past, unfortunately our domain for whatever reason wasn't deemed beyond reproach by gmail et al. At first it they blocked around 5% of emails eventually this went up to nearly 9%, aside from those that got blocked some just disappeared into a void after being accepted by gmail and took upwards of 20 mins to a few hours to be delivered.
- techsupporter 10y ago
  > ...unfortunately our domain for whatever reason wasn't deemed beyond reproach by gmail et al. ... aside from those that got blocked some just disappeared into a void after being accepted by gmail... This is why I have started to really loathe GMail. I get that spam is a problem but, periodically, Google decides to shit-can e-mails from me to their subscribers with no notification to me or the recipient. I know for an absolute fact that no one sends spam from my server because I'm the only person who uses that server and it has no mail-sending scripts on it. My DKIM and SPF records are configured and working, my sending IPs have been consistent for years, and my domain's registration predates the existence of Google[0]. But still, every 4 months or so, Google decides to get its hackles up for a few days and then everything goes back to normal. 0 - This is maybe one reason that compounds my frustration because I've been on the Internet long enough to remember when this wasn't a problem and when mail admins could talk to each other to resolve things like this.
hossbeast 10y ago
How do you pronounce it?
- scrollaway 10y ago
  Por-tee-ay
fourbnine 10y ago
I hope the needs of providers like Fastmail (who provide services at users domains) are top of mind for the people behind this project as it's difficult to see it getting traction if it can't be deployed en-mass by hosting providers.
qud 10y ago
Emails are not unique, lots of companies assign employees emails that would later be used by another person.
- johannes1234321 10y ago
  That is an issue not spezific to this tool. It's an issue with all tools offering "Lost password" features. Nowadays everybody should be able to get personalized mail addresses.
shazow 10y ago
Is there a process for migrating to a different email address? Let's say I used my work address to sign into a bunch of stuff, but then I leave my job and I lose access to my email address? Or say I'm migrating from using @gmail.com for everything to using my own domain?
- callahad 10y ago
  Portier is an implementation detail for the websites you're using -- it doesn't do anything but validate addresses, and it doesn't have any kind of persistent database. It'd be up to the sites you're using to have some sort of address changing mechanism, just as if they were using a traditional username/password system. One tradeoff of Portier's approach is that you can't authenticate if you lose access to your email account. This can be a pain in the ass in some cases, but beneficial in others -- pull someone from your company's LDAP and they can't represent themselves with that email address anymore. Tradeoffs :/
  - WorldMaker 10y ago
    This was a criticism I heard a bunch while I was trying to evangelize Persona. Persona and Portier almost replace all of the guts of a user database, except for small needs of user profiles (which will likely forever be site specific) and user continuity, which is a much bigger issue and the source of the most pushback against Persona I heard from potential site owners. User continuity and conjunction (as a user here are three emails that all represent "me"; this one I used in the past but cannot access now; this one is my "primary") is definitely a complicated problem and there are definitely some domains (corporate) that need to be stricter with what they allow than others. The best argument I found was that all of the major website frameworks in use today (Rails, ASP.NET, Laravel, Django, what have you) provide in the box solutions for user continuity given the existing "standard" of username/password connected to an assortment of email addresses and/or OpenID Connect connections. The easiest way to implement Persona (or Portier) in most frameworks and continue to take advantage of built-in user continuity was as "yet another vaguely OpenID Connect"-like option in the potential giant wall of login brands, which means that it competes with Facebook/Google/GitHub/et al login for mental brand space. Obviously there is no "easy" answer here, but it would definitely help sell Portier to potential sites if there were some answers. Perhaps some sort of user continuity service (or service options) would be useful as another microservice in a "Portier ecosystem" even if it is just barely on par with the built-in templates of the average web framework today. That could help make it easier to "sell" it as a drop-in replacement for all of the bulky weight of web framework user systems rather than "yet another login option in a sea of them".
andmarios 10y ago
Cool! Caddy webserver supports something similar I think —minus the google sign-in: https://caddyserver.com/docs/multipass https://caddyserver.com/docs/multipass
- namsral 10y ago
  Hi, I'm the dev. https://github.com/namsral/multipass https://github.com/namsral/multipass Multipass is email provider agnostic, any email address can be used to authenticate users without a password. It's up to the service maintainer to handle authorisation. Multipass is available as a Caddy plugin, a single binary and can be included in your Go project.
drdaeman 10y ago
Maybe I'm heavily misunderstanding how this whole thing works, but isn't it basically a django-allauth/passport.js/omniauth/... packed as a [micro]service, with an "click link in email" for the fallback algorithm, and a planned "self-hosted" option (not sure how it would be any conceptually different from classic OpenID)? Calling this a spiritual successor to Persona looks like a big stretch to me... Maybe I got it all wrong, though. (And still I don't like it anyway, because my pet peeve is not having identity providers at all - one's identity must be something they can actually own, not something they lease from a provider, be it an email service or domain registrar...)
- StavrosK 10y ago
  > isn't it basically a django-allauth/passport.js/omniauth/... packed as a [micro]service, with an "click link in email" for the fallback algorithm, and a planned "self-hosted" option (not sure how it would be any conceptually different from classic OpenID)? Yes, in the same way that everything is composed of other things.
- callahad 10y ago
  Yes. It's multi-provider authentication as a service. I think this matters, since it means I can run a single instance to support all of my projects, regardless of language, because everything speaks HTTP. I don't have to grapple with OmniAuth for Ruby, AllAuth for Python, Passwordless for Node, and lord knows what for experiments in Clojure, Elixir, and Rust. I don't have to set up outbound email, register social API keys, and design a hybrid login form for each of those projects, either. Set up Portier once, and I'm done. I've written more about Persona's failings and virtues at https://github.com/portier/portier.github.io/blob/master/OtherProjects.md https://github.com/portier/portier.github.io/blob/master/Oth..., which might better explain why I view this as a successor. As to Identity Providers... as long as websites utilize email addresses as a way of identifying accounts and resetting passwords, we're in the same place. Portier makes this no worse. I sympathize with the notion that identity should not be leased from a third party, but I don't know how to solve that. Blockchains? I'd encourage others to pursue that future while Portier tries to carve out an ephemeral but useful island in the present.

206 points by samps 10y ago

Real question here is 'why isn't auth built in to the browser'. Lack of browser support is the reason oauth is so complicated (it relies on HTTP redirect to pass information around). Imagine a web experience sans cookies and sans JS. If you take into account the economics of content, it can only happen with browser-mediated login.

ejcx 10y ago
It is* Credential Management[1] is newly ratified (or will be ratified soon I lose track at this point. Mike West works fast). Either way, the api is exposed to chrome. The best I can understand is that Google and Apple both want to store your passwords in the browser/keyring, and sync them between your devices. Apple has begun "suggesting" passwords in Safari that are fairly strong. It's scary to think about, but "browser" is already the most used "password manager". It just is not full featured yet. [1] https://w3c.github.io/webappsec-credential-management/ https://w3c.github.io/webappsec-credential-management/ * you are using chrome
aethertron 10y ago
Could it be done in a non-spoofable, decentralised way? Xanadu is/was specified to include user authentication. No idea about the implementation there.
- jamesgeck0 10y ago
  Yes. Mozilla Persona was explicitly designed with the intent of having auth as a feature in every browser.
deleted 10y ago
[deleted]
pmontra 10y ago
Basically you're asking for an authentication standard. Some de facto standards are completely client side. Browsers embed at least the "fill form/remember password" authentication method. It's not a standard and some people use it. Some people use an external password manager instead (I do, keepassx). Some password managers come with addons for the major browsers. Other people don't use anything and try to remember passwords, sorry for them. Maybe your question was why don't browsers embed oauth? About the sans cookies experience, with oauth or without it, there should be a standard way for browsers to send authentication info in the request. I don't see another way, but I might be wrong. Basic auth is a way, cookies are another. Both are ok only with https. What do you suggest instead?
callahad 10y ago
In the long run, authentication should be baked into browsers, and it seems like FIDO U2F is making decent strides in that arena. For right now, I think Portier hits a sweet spot for smaller sites without a lot of time or energy to put into building out bespoke authentication integrations.
tomjen3 10y ago
It is, and has been since god knows when: client certificates. Better than passwords because they can't be phised, doesn't require an email, doesn't require trusting any third-party service. Unfortunately they are also very difficult to understand for even normal geeks and so basically no site use them.
- drdaeman 10y ago
  It's not hard to understand ("you have the key, in a form of file or a hardware token, use it to open your account" is something average grandma can grok - no harder than passwords), but current UI and UX are terrible. Then it's chicken-and-egg problem: no one uses certificates because they're unuseable, and no one works on their usability because no one uses them.
closeparen 10y ago
Client cert support has been built into the browser for a long time. One problem is that you basically have to build out non-cert authentication to give people certs to install. That, and there's little to no mutual trust, so every institution needs to issue and manage its own certs.
- bradleyjg 10y ago
  If the client certificate distribution problem was a one-time per site thing it wouldn't be so bad. The issue is that people want to be able to use multiple browsers on multiple devices, and some of those browsers are in use by multiple people.
  - drdaeman 10y ago
    In theory, it's well possible to sync keystores (just like browsers sync passwords), or issue multiple certificates for a single account. There are a lot of options and scenarios well possible (no single size fits all, of course) In practice, anything related to client certificates in browsers is not usable.
    - bradleyjg 10y ago
      If you are authenticating all the time to a sync server or a certificate granting server than that ends up being the real login process.
      - drdaeman 10y ago
        Yes, it is a login process and there has to be one somewhere under the hood. Whatever the scheme is - at some point, one has to authenticate. The trick is, you set it up once and then your user agent does it for you, so all you have to do is set up sync (or any other option) once then never bother but just hit the "okay, log me in here" buttons, optionally, choosing an identity (certificate) if you have many.
nickpsecurity 10y ago
We tried: https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... http://srp.stanford.edu/ http://srp.stanford.edu/ Just not getting adoption it needs IIRC. Could be other explanation.
kruhft 10y ago
Auth is built into the browser[1], it's just ugly (popups) and nobody uses it. [1] HTTP Basic Auth
- WorldMaker 10y ago
  Nobody uses it because: 1) HTTP Basic Auth sends passwords over plaintext. (Digest Auth at least hashes passwords, but isn't a huge security win either.) 2) Basic Auth still requires user management and if you are going to build a user management database you might as well build a login flow in HTML instead of basic auth (not just because basic auth is ugly but because you can own that login flow and provide handy things like password recovery which basic auth doesn't support). As pointed out elsewhere, HTTPS Client Certificates are a much better option baked into every browser, but we've never figured out the UX to make it convenient for the average user.
  - zimpenfish 10y ago
    As a counterpoint, https://www.rdegges.com/2015/why-i-love-basic-auth/ https://www.rdegges.com/2015/why-i-love-basic-auth/

callahad 10y ago

Hi! A few of us have been hacking on this scaled-down, spiritual successor to Persona. The core idea is that you treat this (self-hostable!) microservice like a black box: email address goes in, validated proof of identity comes out. No passwords, and no secrets to store in your application’s database. The service itself is also effectively stateless: aside from caching, the longest lived key in Redis has a TTL of 15 minutes, and no other datastore is required. So it should scale pretty reasonably, and be easy enough to administer for hobbyists. Behind the scenes, it works similarly to a password reset or passwordless login workflow, but with progressive enhancement so that, e.g., Gmail users go through Google Sign-In instead of having to check their email.

plttn 10y ago
>Behind the scenes, it works similarly to a password reset or passwordless login workflow, but with progressive enhancement so that, e.g., Gmail users go through Google Sign-In instead of having to check their email. I mean there's really nothing you can do about it, but it doesn't handle Google Apps / G Suite / whatever today's flavor of white-label Google services is. If I use my email which is a Google Apps account, I don't get the Google Sign-In enhancement, I get an email.
- callahad 10y ago
  We discussed this in https://github.com/portier/portier-broker/issues/44 https://github.com/portier/portier-broker/issues/44, and unfortunately don't think there's a good way to blanket-enable support for G Suite domains. :( I'd really love to make this possible in the near future. Maybe an opt-in flag? Or finishing up our federated protocol and building a tiny service that bridges between that and G-Suite? Suggestions / feedback into that bug would be really helpful.
  - tscs37 10y ago
    A possible solution would be a DNS TXT entry (some with custom mail domains will have some sort of access to their DNS), which Portier could look up and use to determine if the service supports some form of OAuth. Alternatively, if DNS is not applicable, users could use filters and autoresponders to send back an automatic response with some code. In theory that would basically mean "Portier sends Login Mail" -> "Login Mail gets bounced via filter with additional code" -> "Portier constructs OAuth Link" -> "Portier sends OAuth back"

SimeVidas 10y ago

Note that Mozilla Persona did not support passwordless authentication. Specifically, you would still need to create a Persona password if you didn’t use a Gmail/Yahoo email address. I’ve tested this service with one of those 10-minute emails and it seems to work without any passwords, so true passwordless authentication.

callahad 10y ago
Yep! Requiring a separate account for Persona was, in hindsight, misguided. I've written a bit about what Persona got right and wrong, and how we* plan for Portier to be different, at https://github.com/portier/portier.github.io/blob/master/OtherProjects.md#portier-compared-to-persona https://github.com/portier/portier.github.io/blob/master/Oth... *Though Mozilla supported my work on this, Portier is an independent side project with significant code contributions from folks outside Mozilla.

overcast 10y ago

I dream of the day all logins are just simple tokens. Either sent through email, or SMS. So sick of passwords. I've used other Passwordless libraries on a few projects, and it's almost cathartic.

StavrosK 10y ago
The problem with that is that it breaks a user's flow too much :/ It's a good fallback, and it has many benefits, but having to switch contexts to the mail client and wait for an email is too cumbersome for the user (although it's not too bad when paired with a long-lived session). That's why Portier supports other auth providers, so you can have the best of both worlds.
- overcast 10y ago
  Yes, and thus the reason it hasn't caught on. It's such a better idea than 75% of the passwords being Winter2016 though.
  - StavrosK 10y ago
    Agreed on both counts. Given the imminent Persona shutdown, and until I can move it to Portier, I've implemented it on Pastery as a stopgap: https://www.pastery.net/login/ https://www.pastery.net/login/ I think it works quite well (the session lasts until you log out).
    - overcast 10y ago
      Did similar at Link Packets, http://linkpackets.com/ http://linkpackets.com/ - more of a proof of concept / handy thing project.
- Sir_Substance 10y ago
  >The problem with that is that it breaks a user's flow too much :/ Unironically and without rancor, would you say it breaks a users flow more or less than having to go fire up their password manager and find the service from dozens of entries? The number of services we use daily is increasing, and they just keep getting hacked. The idea of actually memorizing your password is rapidly becoming impractical. Most people these days who understand password security have either developed a personal algorithm for deriving passwords, or use a password manager for literally everything. I'm super glad someone has done this, because it means I don't have to get off my arse and do it, and lord knows I love laziness. Generally speaking, for websites that I log into less than once a month, I reset my password every time I log into them, and set it to a random and long keyboard smashing every time I do so. This is the same workflow, but without having to use notepad to stage the new "password" for entry into the confirmation field.

fiatjaf 10y ago

Are there any free public servers we can use for side-projects?

callahad 10y ago
We're literally running this on a hobby-tier Heroku dyno, with free-level redis and smtp services and doing fine at the tens-of-requests-per-minute rate. So you should be able to host your own! :) Once we implement https://github.com/portier/portier-broker/issues/88 https://github.com/portier/portier-broker/issues/88, it'll even be a 2-click process to get going. We do intend to keep https://broker.portier.io https://broker.portier.io online as a public service / reference implementation, but we don't have anyone on call or anything if it falls over. On the upside, the Broker is written in Rust, so it shouldn't segfault all that often. ;)

fiatjaf 10y ago

Is it possible to create an email-like service that doesn't actually handle email, but only serves as an identity endpoint to be used with Portier? Like, say, I create an account that reads "me@fiatjaf.com" and implement something on my fiatjaf.com server so that I can use it to login using Portier?

StavrosK 10y ago
Yes, it's an OIDC-compatible flow, so if fiatjaf.com implements an OIDC provider that will authenticate "me", you should be good.
callahad 10y ago
It will be! We're not sure what the eventual protocol will look like, but it'll probably start with webfinger, which can then point to whatever authentication gateway you want. We only need SMTP as the base case in the chain of strategies: https://github.com/portier/portier.github.io/blob/master/Design.md https://github.com/portier/portier.github.io/blob/master/Des...
- fourbnine 10y ago
  At the risk of stating the obvious choosing webfinger implicitly excludes anyone who does not or can not control their website sufficiently to implement webfinger. (ie: hosted webservices similar to Tumblr et al)
  - fiatjaf 10y ago
    That's perfect. If you do not own the domain you shouldn't be able to use the domain like that.
    - fourbnine 10y ago
      Owning the domain is not the same thing as fully controlling the web service. My use of Tumblr as an example rather than simply stating hosted-CMS has probably misconstrued my point. (I use Tumblr with my own domain and forget that it is primarily not used that way.)

chaz6 10y ago

This sounds an awful lot like OpenID (2). What makes it different? My OpenID login (aka XRI i-name) is "=chris.hills" and works on sites that support it.

callahad 10y ago
There's a little more discussion of that over on Lobsters: https://lobste.rs/s/fkosun/ https://lobste.rs/s/fkosun/. The TL;DR is that URIs just didn't work for the mass public. You had to supplement the login form with a NASCAR-esque wall of logos, which was awful for different reasons. Thus, Portier, and Persona before it, chose to identify users by email addresses. I talk a little bit about that at 9:05 in my PyCon 2013 talk on Persona: https://www.youtube.com/watch?v=nJff23UdNAI#t=9m05 https://www.youtube.com/watch?v=nJff23UdNAI#t=9m05

callahad 10y ago

Postmark just dropped our outbound email for high bounce rates. Falling back to SendGrid :/ Try again in 5 minutes. Edit: Ask HN: Any suggestions for solving this? Hitting the frontpage means people are spamming the login form with bogus addresses like a@a.com that bounce and cause trouble for us and the ESPs. Not ideal, but I'm not sure how to solve this for a small scale side-project. Discussion in https://github.com/portier/portier-broker/issues/96 https://github.com/portier/portier-broker/issues/96

danieltillett 10y ago
I think you have just discovered the fundamental flaw of your approach. My only suggestion is send the first email from your own server and if this does not bounce then send again from postmark. I used to use a telnet based approach to check if the account exists, but most servers these day don't respond with the correct error response if an account does not exist.
- callahad 10y ago
  I'm not sure it's a fundamental flaw: it's exactly identical to sending a confirmation email when a user signs up for a website, which is considered a best practice on the Web. If that works well enough for the Web at large, it should work here, too. As far as I can tell, the trick is building up that initial reputation and doing as much mitigation as possible up front: checking for MX records, rate limiting, soft-failing with CAPTCHAs for things that look suspicious, etc. I know what I'll be hacking on for the rest of the week. :)
  - danieltillett 10y ago
    I should have phrased this differently - it is the fundamental flaw of all email based authentication systems. Your approach is currently a bit more prone to problems since you are one nasty script away from being bounced out of existence. Yes you need to protect the log in page by rate limiting, Captcha, looking up mx records, etc. One approach I have thought would be good to use is a rainbow table like approach. Most people are not very imaginative about the fake email accounts they use.

woodcut 10y ago

I tried purely email based authentication in the past, unfortunately our domain for whatever reason wasn't deemed beyond reproach by gmail et al. At first it they blocked around 5% of emails eventually this went up to nearly 9%, aside from those that got blocked some just disappeared into a void after being accepted by gmail and took upwards of 20 mins to a few hours to be delivered.

techsupporter 10y ago
> ...unfortunately our domain for whatever reason wasn't deemed beyond reproach by gmail et al. ... aside from those that got blocked some just disappeared into a void after being accepted by gmail... This is why I have started to really loathe GMail. I get that spam is a problem but, periodically, Google decides to shit-can e-mails from me to their subscribers with no notification to me or the recipient. I know for an absolute fact that no one sends spam from my server because I'm the only person who uses that server and it has no mail-sending scripts on it. My DKIM and SPF records are configured and working, my sending IPs have been consistent for years, and my domain's registration predates the existence of Google[0]. But still, every 4 months or so, Google decides to get its hackles up for a few days and then everything goes back to normal. 0 - This is maybe one reason that compounds my frustration because I've been on the Internet long enough to remember when this wasn't a problem and when mail admins could talk to each other to resolve things like this.

hossbeast 10y ago

How do you pronounce it?

scrollaway 10y ago
Por-tee-ay

fourbnine 10y ago

I hope the needs of providers like Fastmail (who provide services at users domains) are top of mind for the people behind this project as it's difficult to see it getting traction if it can't be deployed en-mass by hosting providers.

qud 10y ago

Emails are not unique, lots of companies assign employees emails that would later be used by another person.

johannes1234321 10y ago
That is an issue not spezific to this tool. It's an issue with all tools offering "Lost password" features. Nowadays everybody should be able to get personalized mail addresses.

shazow 10y ago

Is there a process for migrating to a different email address? Let's say I used my work address to sign into a bunch of stuff, but then I leave my job and I lose access to my email address? Or say I'm migrating from using @gmail.com for everything to using my own domain?

callahad 10y ago
Portier is an implementation detail for the websites you're using -- it doesn't do anything but validate addresses, and it doesn't have any kind of persistent database. It'd be up to the sites you're using to have some sort of address changing mechanism, just as if they were using a traditional username/password system. One tradeoff of Portier's approach is that you can't authenticate if you lose access to your email account. This can be a pain in the ass in some cases, but beneficial in others -- pull someone from your company's LDAP and they can't represent themselves with that email address anymore. Tradeoffs :/
- WorldMaker 10y ago
  This was a criticism I heard a bunch while I was trying to evangelize Persona. Persona and Portier almost replace all of the guts of a user database, except for small needs of user profiles (which will likely forever be site specific) and user continuity, which is a much bigger issue and the source of the most pushback against Persona I heard from potential site owners. User continuity and conjunction (as a user here are three emails that all represent "me"; this one I used in the past but cannot access now; this one is my "primary") is definitely a complicated problem and there are definitely some domains (corporate) that need to be stricter with what they allow than others. The best argument I found was that all of the major website frameworks in use today (Rails, ASP.NET, Laravel, Django, what have you) provide in the box solutions for user continuity given the existing "standard" of username/password connected to an assortment of email addresses and/or OpenID Connect connections. The easiest way to implement Persona (or Portier) in most frameworks and continue to take advantage of built-in user continuity was as "yet another vaguely OpenID Connect"-like option in the potential giant wall of login brands, which means that it competes with Facebook/Google/GitHub/et al login for mental brand space. Obviously there is no "easy" answer here, but it would definitely help sell Portier to potential sites if there were some answers. Perhaps some sort of user continuity service (or service options) would be useful as another microservice in a "Portier ecosystem" even if it is just barely on par with the built-in templates of the average web framework today. That could help make it easier to "sell" it as a drop-in replacement for all of the bulky weight of web framework user systems rather than "yet another login option in a sea of them".

andmarios 10y ago

Cool! Caddy webserver supports something similar I think —minus the google sign-in: https://caddyserver.com/docs/multipass https://caddyserver.com/docs/multipass

namsral 10y ago
Hi, I'm the dev. https://github.com/namsral/multipass https://github.com/namsral/multipass Multipass is email provider agnostic, any email address can be used to authenticate users without a password. It's up to the service maintainer to handle authorisation. Multipass is available as a Caddy plugin, a single binary and can be included in your Go project.

drdaeman 10y ago

Maybe I'm heavily misunderstanding how this whole thing works, but isn't it basically a django-allauth/passport.js/omniauth/... packed as a [micro]service, with an "click link in email" for the fallback algorithm, and a planned "self-hosted" option (not sure how it would be any conceptually different from classic OpenID)? Calling this a spiritual successor to Persona looks like a big stretch to me... Maybe I got it all wrong, though. (And still I don't like it anyway, because my pet peeve is not having identity providers at all - one's identity must be something they can actually own, not something they lease from a provider, be it an email service or domain registrar...)

StavrosK 10y ago
> isn't it basically a django-allauth/passport.js/omniauth/... packed as a [micro]service, with an "click link in email" for the fallback algorithm, and a planned "self-hosted" option (not sure how it would be any conceptually different from classic OpenID)? Yes, in the same way that everything is composed of other things.
callahad 10y ago
Yes. It's multi-provider authentication as a service. I think this matters, since it means I can run a single instance to support all of my projects, regardless of language, because everything speaks HTTP. I don't have to grapple with OmniAuth for Ruby, AllAuth for Python, Passwordless for Node, and lord knows what for experiments in Clojure, Elixir, and Rust. I don't have to set up outbound email, register social API keys, and design a hybrid login form for each of those projects, either. Set up Portier once, and I'm done. I've written more about Persona's failings and virtues at https://github.com/portier/portier.github.io/blob/master/OtherProjects.md https://github.com/portier/portier.github.io/blob/master/Oth..., which might better explain why I view this as a successor. As to Identity Providers... as long as websites utilize email addresses as a way of identifying accounts and resetting passwords, we're in the same place. Portier makes this no worse. I sympathize with the notion that identity should not be leased from a third party, but I don't know how to solve that. Blockchains? I'd encourage others to pursue that future while Portier tries to carve out an ephemeral but useful island in the present.