Portier – An email-based, passwordless authentication service(portier.github.io)
portier.github.io
Portier – An email-based, passwordless authentication service
https://portier.github.io/
88 comments
>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.
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.
We discussed this in 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.
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.
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"
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"
An auto responder wouldn't have access to the user that made the request's cookies, and therefore would be unable to actually authenticate the user. You'd wind up with a system where anyone that knew your email would be able to log in as you, which is a rather bad idea.
The autoresponder is more of a "This domain accept OAuth" and sends back the email body.
That way, the autoresponder doesn't need to know anything about the process nor does it authenticate the user.
It merely sends back a mail that portier can interprete as "Ok, I send an auth email there and this response means they want me to construct an oauth link to this domain"
it's stateless and only requires a rather simple autoresponder that can include email bodies.
Furthermore, portier can also verify the login link, so that replay attacks aren't feasible and the sender and link-owner must have matching emails.
That way, the autoresponder doesn't need to know anything about the process nor does it authenticate the user.
It merely sends back a mail that portier can interprete as "Ok, I send an auth email there and this response means they want me to construct an oauth link to this domain"
it's stateless and only requires a rather simple autoresponder that can include email bodies.
Furthermore, portier can also verify the login link, so that replay attacks aren't feasible and the sender and link-owner must have matching emails.
Email filters and autoresponders are a bit convoluted to expect wide adoption. A TXT record might work though. Is a referral in a TXT record any worse from a security perspective than a referral in an MX record?
Manipulating DNS is sadly very easy, but a TXT record of this type should be better than a MX record, as long as a oauth signin also contains a normal login link.
In this case, the worst-case is an attacker injecting a TXT record to force OAuth logins via that domain... which is a bit pointless as far as I can see, it either won't work or use the victim's own oauth service, for which they are responsible themselves IMO.
In this case, the worst-case is an attacker injecting a TXT record to force OAuth logins via that domain... which is a bit pointless as far as I can see, it either won't work or use the victim's own oauth service, for which they are responsible themselves IMO.
I read that you're not planning to integrate with Facebook[1], but what about other providers, if they allow you to request access to almost nothing? Perhaps, for example, allowing people to use <their-name>@github.com would prompt them with a GitHub OAuth screen and identify them. Why not?
I see, it is not a valid email. Maybe there should be a Portier fork that implemented stuff like that, though.
[1]: https://github.com/portier/portier.github.io/blob/master/Non...
I see, it is not a valid email. Maybe there should be a Portier fork that implemented stuff like that, though.
[1]: https://github.com/portier/portier.github.io/blob/master/Non...
To me, that sounds like a useful shorthand. It would probably not at all be difficult to add support for that to the broker (apart from the usual wrestling with Rust), so yeah, why not. Though I maybe miss some implications for the RP – breaking the expectation that it is just an email is bad if you use the email as an email, and if you want to have the option to easily move away from portier.
The FB thing was more, iirc, that you don't want to enter an email and then get the FB dialogue just because you used your email on FB.
The FB thing was more, iirc, that you don't want to enter an email and then get the FB dialogue just because you used your email on FB.
Great to hear that you continue to iterate on Persona idea. It is a little pity that Portier wasn't announced earlier, preferably together with Persona shutdown decision. Many sites that are using Persona already migrated login flows and would likely consider Portier if it was an option.
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 [email protected] 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
Edit: Ask HN: Any suggestions for solving this? Hitting the frontpage means people are spamming the login form with bogus addresses like [email protected] 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
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.
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.
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. :)
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. :)
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.
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.
One workaround might be to request that the user send an initial email to your servers from their address before attempting the authentication. You'd want to validate that the email arrived and is valid according to SPF/DKIM/DMARC. You might consider allowing only messages that are positively authenticated by one of those technologies (not e.g. vacuously valid for lack of SPF records). Admittedly this will require a more complex user interaction, but it will avoid the abuse problem you're describing. You could make sending this email easy by supplying an appropriately filled out mailto: link; it should be enough to click it and send. You'd then follow this up with your current authentication step.
I've been thinking about this space for a while (e.g. https://news.ycombinator.com/item?id=12411204 ) and would be happy to chat or brainstorm.
I've been thinking about this space for a while (e.g. https://news.ycombinator.com/item?id=12411204 ) and would be happy to chat or brainstorm.
There are a handful of (commercial) email address verification services, which could automate some of the logic for you:
* https://kickbox.io * https://www.emailhippo.com * http://www.briteverify.com
The pricing might be prohibitive for your usage. I don't know if any of them offer discounts/free usage for open source projects. (Not endorsing any of them; they've been sitting on my own list of things to investigate.)
Also, as an aside: SendGrid may not be suitable for transactional email you need delivered consistently quickly, unless you purchase their dedicated IP option. (And if you're bouncing a lot, a dedicated IP could actually be counterproductive for your delivery.) Recent incident [https://sendgrid.com/docs/Classroom/Deliver/shared_ip_thrott...] and discussion [https://news.ycombinator.com/item?id=12142728].
* https://kickbox.io * https://www.emailhippo.com * http://www.briteverify.com
The pricing might be prohibitive for your usage. I don't know if any of them offer discounts/free usage for open source projects. (Not endorsing any of them; they've been sitting on my own list of things to investigate.)
Also, as an aside: SendGrid may not be suitable for transactional email you need delivered consistently quickly, unless you purchase their dedicated IP option. (And if you're bouncing a lot, a dedicated IP could actually be counterproductive for your delivery.) Recent incident [https://sendgrid.com/docs/Classroom/Deliver/shared_ip_thrott...] and discussion [https://news.ycombinator.com/item?id=12142728].
Oh, also, another resource if you want to roll your own email verification: https://www.scottbrady91.com/Email-Verification/Python-Email...
Do you have a plan for users whose mail server does greylisting?
Having to wait 20 minutes to receive an e-mail so that i can login would be a real PITA.
Also, "recipient verification" (which some others have managed) isn't a good long-term solution.
Having to wait 20 minutes to receive an e-mail so that i can login would be a real PITA.
Also, "recipient verification" (which some others have managed) isn't a good long-term solution.
That's a really good question, because there's no plan yet. In fact, Portier currently doesn't allow more than 15 minutes for verification.
Lots of services already depend on email verification during signup or password recovery. I'd love to know, have you seen any interesting solutions around greylisting in the wild?
Lots of services already depend on email verification during signup or password recovery. I'd love to know, have you seen any interesting solutions around greylisting in the wild?
> have you seen any interesting solutions around greylisting in the wild?
To "bypass" or somehow defeat greylisting, you mean?
I'm not aware of any via workarounds, no. I would certainly be interested in hearing about any , though, since I use greylisting on mail servers with thousands of users.
In some cases, such as when using OpenBSD's spamd [0], you (an SMTP client) don't even get to talk to the "real" SMTP server until you've successfully "passed the tests". This is the primary implementation of greylisting that I use, FWIW.
[0]: http://man.openbsd.org/OpenBSD-current/man8/spamd.8
To "bypass" or somehow defeat greylisting, you mean?
I'm not aware of any via workarounds, no. I would certainly be interested in hearing about any , though, since I use greylisting on mail servers with thousands of users.
In some cases, such as when using OpenBSD's spamd [0], you (an SMTP client) don't even get to talk to the "real" SMTP server until you've successfully "passed the tests". This is the primary implementation of greylisting that I use, FWIW.
[0]: http://man.openbsd.org/OpenBSD-current/man8/spamd.8
What about only explicitly allowing domains that have DKIM enabled?
Having that form of validation should help since DKIM was made to specifically stop email spoofing; and anyone serious about implementing Portier would understand that need.
Outlook/Gmail etc aren't likely to be flagged by ESP's for the most part as those have reputation and rudimentary spoofing protection, at least more than [email protected] anyway.
Persons using custom domains are usually the admins of those domains, and Office 365/GApps/Registrars etc. provide simple ways to enable DKIM.
Having that form of validation should help since DKIM was made to specifically stop email spoofing; and anyone serious about implementing Portier would understand that need.
Outlook/Gmail etc aren't likely to be flagged by ESP's for the most part as those have reputation and rudimentary spoofing protection, at least more than [email protected] anyway.
Persons using custom domains are usually the admins of those domains, and Office 365/GApps/Registrars etc. provide simple ways to enable DKIM.
In response to your other (dead) comment, "SPF" records actually are TXT records.
In the past, there was an SPF RR type but that's been deprecated.
In the past, there was an SPF RR type but that's been deprecated.
Depending on what kind of bounces they penalize you for, making sure the domain has a valid MX record before you send the mail might help.
Won't help if you get flooded with a bunch of invalid usernames at a big email provider, but as your volume of legitimate volume grows the bad ones should hurt less.
Won't help if you get flooded with a bunch of invalid usernames at a big email provider, but as your volume of legitimate volume grows the bad ones should hurt less.
Hopefully the OP already knows this but (just in case) an MX is not required. An A RR will be tried if an MX doesn't exist.
Exactly, which is why validating the MX is better than merely testing for NXDOMAIN. If you try delivering to something with implicit MX it is far more likely to fail than something with proper MX records. It's also more likely to fail because the A record doesn't point to a host running SMTP, so your provider will be forced to queue it and keep retrying. SMTP servers pointed to by stale MX records are much more likely to return permanent failure right away.
Nobody who actually cares about reliably receiving mail should depend on implicit MX. Of all the things mail administrators have to do these days, like reverse lookup, SPF, and DKIM, is it reasonable to care about anyone who can't be bothered with MX records?
I'd gladly reject such domains if doing so improved overall mail delivery rate to popular domains. And unlike 99% of situations where an email fails to show up, the sending web site can instantly report the reason for failure.
Nobody who actually cares about reliably receiving mail should depend on implicit MX. Of all the things mail administrators have to do these days, like reverse lookup, SPF, and DKIM, is it reasonable to care about anyone who can't be bothered with MX records?
I'd gladly reject such domains if doing so improved overall mail delivery rate to popular domains. And unlike 99% of situations where an email fails to show up, the sending web site can instantly report the reason for failure.
You bring up a very good point that I hadn't really thought of before ("... is it reasonable to care about anyone who can't be bothered with MX records?") but that has caused me to stop and think.
I manage e-mail systems with thousands of users and a fair number of domains as well. In most cases, I also manage the authoritative DNS servers for these domains so I make sure that all the appropriate records (MX, TXTs for SPF, DKIM, etc.) are set up properly.
You're right, though. If example.com hasn't bothered setting up an MX record for example.com -- even if mail is hosted on the same machine as identified in the A RR -- they probably aren't worth worrying about. It seems reasonable to conclude that they really aren't too concerned about being able to receive mail.
I manage e-mail systems with thousands of users and a fair number of domains as well. In most cases, I also manage the authoritative DNS servers for these domains so I make sure that all the appropriate records (MX, TXTs for SPF, DKIM, etc.) are set up properly.
You're right, though. If example.com hasn't bothered setting up an MX record for example.com -- even if mail is hosted on the same machine as identified in the A RR -- they probably aren't worth worrying about. It seems reasonable to conclude that they really aren't too concerned about being able to receive mail.
briteverify is very good at detecting bogus emails, however it's not terribly cheap.
Why not just take the demo page down, at least for now? The concept is very simple.
Why dont you add a captcha?
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.
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.
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/
* you are using chrome
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/
* you are using chrome
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.
Unfortunately they are also very difficult to understand for even normal geeks and so basically no site use them.
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.
We tried:
https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
http://srp.stanford.edu/
Just not getting adoption it needs IIRC. Could be other explanation.
https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
http://srp.stanford.edu/
Just not getting adoption it needs IIRC. Could be other explanation.
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.
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.
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?
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?
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.
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.
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.
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.
In practice, anything related to client certificates in browsers is not usable.
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.
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.
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.
[deleted]
Could it be done in a non-spoofable, decentralised way?
Xanadu is/was specified to include user authentication. No idea about the implementation there.
Xanadu is/was specified to include user authentication. No idea about the implementation there.
Yes. Mozilla Persona was explicitly designed with the intent of having auth as a feature in every browser.
Auth is built into the browser[1], it's just ugly (popups) and nobody uses it.
[1] HTTP Basic Auth
[1] HTTP Basic Auth
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.
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.
As a counterpoint, https://www.rdegges.com/2015/why-i-love-basic-auth/
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.
I’ve tested this service with one of those 10-minute emails and it seems to work without any passwords, so true passwordless authentication.
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/Oth...
*Though Mozilla supported my work on this, Portier is an independent side project with significant code contributions from folks outside Mozilla.
*Though Mozilla supported my work on this, Portier is an independent side project with significant code contributions from folks outside Mozilla.
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.
> ...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.
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.
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?
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?
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 :/
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 :/
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".
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".
Cool! Caddy webserver supports something similar I think —minus the google sign-in: https://caddyserver.com/docs/multipass
Hi, I'm the dev. 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.
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.
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 "[email protected]" and implement something on my fiatjaf.com server so that I can use it to login using Portier?
Like, say, I create an account that reads "[email protected]" and implement something on my fiatjaf.com server so that I can use it to login using Portier?
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/Des...
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)
That's perfect.
If you do not own the domain you shouldn't be able to use the domain like that.
If you do not own the domain you shouldn't be able to use the domain like that.
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.)
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.)
Right if your domain is simply CNAMEd to a Tumblr or Blogger or similar hosted CMS you probably have no way to get webfinger in place.
Another example here is any domain that uses static hosting. Lots of domains are hosted on GitHub Pages these days as the obvious big example (but you can replace that with any other static host like Netflify or raw S3 even). The webfinger spec uses query strings to differentiate user requests which means that a static hosted site is at best limited to a single user/email account (by ignoring the query string and returning a static JSON document).
Another example here is any domain that uses static hosting. Lots of domains are hosted on GitHub Pages these days as the obvious big example (but you can replace that with any other static host like Netflify or raw S3 even). The webfinger spec uses query strings to differentiate user requests which means that a static hosted site is at best limited to a single user/email account (by ignoring the query string and returning a static JSON document).
Yes, it's an OIDC-compatible flow, so if fiatjaf.com implements an OIDC provider that will authenticate "me", you should be good.
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...)
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...)
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/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.
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/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.
> Yes. It's multi-provider authentication as a service.
I see. Thanks for clarifying!
I just thought Persona was about privacy (IdPs unaware about identity consumers), and potential browser integration - this was its good points. So, when comparing to Persona, this one looks pale to me.
> Blockchains?
TBH, I don't see any necessity to prove chronologies or require global consensus, unless a globally-unique human-readable identities (like email addresses, but actually owned) are desirable. But are they? I mean, when I walk in some company's reception desk, I don't normally show them some universally recognized ID, I just say "hi, I'm your customer, we had business before - you know me as Aleksey".
Just that I believe it's good to have an authentication protocol (something better than usernames-and-passwords) that is universally accepted, rather than an universally accepted identity. Do you know, does general audience wants it differently?
I see. Thanks for clarifying!
I just thought Persona was about privacy (IdPs unaware about identity consumers), and potential browser integration - this was its good points. So, when comparing to Persona, this one looks pale to me.
> Blockchains?
TBH, I don't see any necessity to prove chronologies or require global consensus, unless a globally-unique human-readable identities (like email addresses, but actually owned) are desirable. But are they? I mean, when I walk in some company's reception desk, I don't normally show them some universally recognized ID, I just say "hi, I'm your customer, we had business before - you know me as Aleksey".
Just that I believe it's good to have an authentication protocol (something better than usernames-and-passwords) that is universally accepted, rather than an universally accepted identity. Do you know, does general audience wants it differently?
> 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.
Yes, in the same way that everything is composed of other things.
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.
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.
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.
That's why Portier supports other auth providers, so you can have the best of both worlds.
>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.
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.
> more or less than having to go fire up their password manager and find the service from dozens of entries?
Definitely more. All good password managers are so well integrated that the username and password are pre-filled in most sites noawadays.
> 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.
Yep, passwords suck.
> This is the same workflow, but without having to use notepad to stage the new "password" for entry into the confirmation field.
Exactly. This just removes all pretense.
Definitely more. All good password managers are so well integrated that the username and password are pre-filled in most sites noawadays.
> 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.
Yep, passwords suck.
> This is the same workflow, but without having to use notepad to stage the new "password" for entry into the confirmation field.
Exactly. This just removes all pretense.
Yes, and thus the reason it hasn't caught on. It's such a better idea than 75% of the passwords being Winter2016 though.
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/
I think it works quite well (the session lasts until you log out).
I think it works quite well (the session lasts until you log out).
Did similar at Link Packets, http://linkpackets.com/ - more of a proof of concept / handy thing project.
Here in China more and more logins are using "scan this QR code with your phone". I think this kind of makes sense for places where you really want to login, and it is very convenient.
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.
There's a little more discussion of that over on Lobsters: 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
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
Emails are not unique, lots of companies assign employees emails that would later be used by another person.
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.
Are there any free public servers we can use for side-projects?
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, it'll even be a 2-click process to get going.
We do intend to keep 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. ;)
We do intend to keep 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. ;)
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.