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

31–40 of 89 posts

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

#31

Post by bradleyjg »

closeparen wrote: post #29
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.

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.

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

#32

Post by woodcut »

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.

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

#33

Post by mixedbit »

callahad wrote: post #8

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…

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.

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

#35

Post by Sir_Substance »

StavrosK wrote: post #15
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.

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.

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

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

#37

Post by tscs37 »

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…

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"

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

#38

Post by nickpsecurity »

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.

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.

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

#39

Post by danieltillett »

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…

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.

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

#40

Post by fourbnine »

callahad wrote: post #23
fiatjaf wrote: post #18

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?

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