Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Portier – An email-based, passwordless authentication service

portier.github.io

Post reply on HN
Print view View original

81–89 of 89 posts

Re: Portier – An email-based, passwordless authentication service

#81

Post by tscs37 »

Vendan wrote: post #80
tscs37 wrote: post #37

Earlier quoted context omitted.

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" -> "Logi…

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.

Re: Portier – An email-based, passwordless authentication service

#82

Post by jlgaddis »

kosinus wrote: post #78
jlgaddis wrote: post #67

Earlier quoted context omitted.

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.

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?

> 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

Re: Portier – An email-based, passwordless authentication service

#83

Post by jlgaddis »

Canada wrote: post #79
jlgaddis wrote: post #66

Earlier quoted context omitted.

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 likel…

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.

Re: Portier – An email-based, passwordless authentication service

#84

Post by namsral »

andmarios wrote: post #58

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.

Re: Portier – An email-based, passwordless authentication service

#85

Post by WorldMaker »

kruhft wrote: post #47
awinter-py wrote: post #2

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.

Auth is built into the browser[1], it's just ugly (popups) and nobody uses it. [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.

Re: Portier – An email-based, passwordless authentication service

#86

Post by zimpenfish »

WorldMaker wrote: post #85
kruhft wrote: post #47

Earlier quoted context omitted.

Auth is built into the browser[1], it's just ugly (popups) and nobody uses it. [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 th…

As a counterpoint, https://www.rdegges.com/2015/why-i-love-basic-auth/

Re: Portier – An email-based, passwordless authentication service

#87

Post by WorldMaker »

fourbnine wrote: post #52
fiatjaf wrote: post #51

Earlier quoted context omitted.

That's perfect. 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.)

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

Re: Portier – An email-based, passwordless authentication service

#88

Post by WorldMaker »

callahad wrote: post #50
shazow wrote: post #46

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?

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…

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

Re: Portier – An email-based, passwordless authentication service

#89

Post by [deleted] »

aidenn0 wrote: post #71
callahad wrote: post #13

Earlier quoted context omitted.

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…

Is it not possible to tell from the MX records if it's a G suite backend?

[deleted]
Post reply on HN