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

71–80 of 89 posts

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

#71

Post by aidenn0 »

callahad wrote: post #13
plttn wrote: post #11

Earlier quoted context omitted.

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

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?

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

#72

Post by bradleyjg »

drdaeman wrote: post #57
bradleyjg wrote: post #31

Earlier quoted context omitted.

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.

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.

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

#73

Post by jcrites »

callahad wrote: post #42
danieltillett wrote: post #39

Earlier quoted context omitted.

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'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-fa…

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.

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

#74

Post by drdaeman »

bradleyjg wrote: post #72
drdaeman wrote: post #57

Earlier quoted context omitted.

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.

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.

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

#75

Post by gbog »

overcast wrote: post #14

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.

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.

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

#76

Post by drdaeman »

callahad wrote: post #64
drdaeman wrote: post #61

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

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

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

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

#77

Post by tscs37 »

fourbnine wrote: post #59
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…

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.

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

#78

Post by kosinus »

jlgaddis wrote: post #67
callahad wrote: post #27

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

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?

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

#79

Post by Canada »

jlgaddis wrote: post #66
Canada wrote: post #45

Earlier quoted context omitted.

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.

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.

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

#80

Post by Vendan »

tscs37 wrote: post #37
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…

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.
Post reply on HN