Integrate ep_hash_auth

The plan for integrating ep_hash_auth into Etherpad was discussed as part of #1650 (see also #3442, #3444, https://github.com/turnkeylinux/tracker/issues/1132).

In https://github.com/LaKing/ep_hash_auth/issues/4 its author agreed to donate its code for allowing the integration. This ticket tracks this work.

[JohnMcLear]

Okay my thoughts on the conversation. Etherpad shouldn’t bring in any further authentication features for user control / management. So with that in mind I respectfully disagree with @JedMeister

But keep reading…

Our skill / experience and passion is in building the editor and integration with various plugins / tools etc. Our skill is not providing a security authentication mechanism or alternative to active directory. Various other services do this (Think Auth0) and they do it very well. We should only ever consume those services for any Secure deployed at scale Etherpad instance. Passport is a great example of a project that should/could be integrated into Etherpad (through a plugin) and would consume hundreds(or is it more now?) authentication service providers, we could and would not want to get involved in trying to duplicate that effort.

So do I think hash of admin password is important? Yes. But any dev/admin putting Etherpad in production where they will be integrating into a larger environment is going to be managing multiple instances with something like docker and be familiar with Python tools. For me, as an example, I close off the /admin front end because I do all my instance management from the CLI and using the scripts provided in bin/

So I think the scope of this should be very close to what @LaKing did, in fact in my opinion I think the plugin approach is completely fine as it provides a great example for others to develop similar auth mechanisms (think certificates as per the comments).

That said, the turnkeylinux project are very against passwords in plain text (and rightly so) so this does leave us with some important considerations… On one hand, we need to be able to empower plugin developers and provide a flexible framework. On the other hand our service consumers want us to provide security out of the box.

I think I have a compromise:

Important point: Currently by default ALL admin users are disabled so an admin has to comment out the admin section to enable /admin…

Why don’t we just have a huge disclaimer for the password section saying, “doing it this way is okay if you are just quickly throwing up a site for your local LAN hack event but if you want a server hitting the Internet you should use ep_hash_auth”…

I don’t think that’s beyond the effort of someone wanting to enable a few plugins… Hell shit, they might even enable a few plugins then just comment back out the auth section and never care about it again… Bringing in loads of complexity for someone a site admin does once in a blue moon, for me, is just burdening a project and reducing it’s ability to deliver it’s core objectives to it’s users.

[JohnMcLear]

Closing as the big warning is in and it appears ep_hash_auth has more users.