Live data from Hacker News

Portier – An email-based, passwordless authentication service

portier.github.io

51–60 of 89 posts

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

#51

Earlier quoted context omitted.

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.

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

#52
post #51

Earlier quoted context omitted.

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.

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

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

#53
post #32

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.

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

#54

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…

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 a@a.com anyway.

Persons using custom domains are usually the admins of those domains, and Office 365/GApps/Registrars etc. provide simple ways to enable DKIM.

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

#55

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…

briteverify is very good at detecting bogus emails, however it's not terribly cheap.

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

#56

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…

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 a@a.com anyway. Persons…

EDIT: Forgot to mention SPF records (actually easier to add to DNS than DKIM, sorry), and saw someone mentioned TXT records too; basically anything that can prove ownership of the domain for non-free addresses.

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

#57

Earlier quoted context omitted.

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.

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.

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

#59
post #37

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…

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?

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

#60
post #19

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.

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.

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