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.
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'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 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...
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.
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.com/portier/portier-broker/issues/96
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.
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. :)
* 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].
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.
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?
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.
In the past, there was an SPF RR type but that's been deprecated.
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.
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.
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
Unfortunately they are also very difficult to understand for even normal geeks and so basically no site use them.
https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
Just not getting adoption it needs IIRC. Could be other explanation.
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.
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?
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.
Xanadu is/was specified to include user authentication. No idea about the implementation there.
[1] HTTP Basic Auth
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.
I’ve tested this service with one of those 10-minute emails and it seems to work without any passwords, so true passwordless authentication.
*Though Mozilla supported my work on this, Portier is an independent side project with significant code contributions from folks outside Mozilla.
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.
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?
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 :/
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".
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.
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?
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...)
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 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?
Yes, in the same way that everything is composed of other things.
That's why Portier supports other auth providers, so you can have the best of both worlds.
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.
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
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. ;)
