Pita/etherpad-lite — Issue #539: Securing pads, access control and IP binding
Author: Annakan
Created: 2012-03-04 21:06:43+00:00
State: open

Hello
First thanks a lot for the work on Etherpad.

I try to understand the security model and how to control access to pads and I have a hard time figuring out (but I am known to be dumb).

## IP Binding

I installed Etherpad lite on a server and started it : Etherpad binds on the external IP : ok I left 0.0.0.0 in the config that means it is the default IP, the external one in my case.

Then I did put **127.0.0.1**, the loop-back and Etherpad *still* binds to my external IP address !!!

That means it always presents its pad creation interface to the whole world ... !!!!

Is it by design ? how can I prevent that ?

The only solution I have in mind is to create a non routable IP adress on my card and see if I can contrive Etherpad to bind **only** to it ... and then do some reverse proxying to it, with some access control scheme tied to my CMS ... I may be way above my head here ...

Is this the way to go ?

## General access model

What is the proper way to have real group pads, meaning having Etherpad **not** present any interface to create pad to the whole world and still provide the service.

I understand that the current model is to have the client to connect directly to the Ethepad Lite server and that means the server program must be reachable from any client.
Do you have plans to allow a model where the Etherpad Server does **not** answer to requests before a handshake, preferably controlled "out of band".
For instance I envision Etherpads to be mostly embedded in various CMS and content management systems and in that case the pad should be created and opened only from that management system, returning a special url to connect to the etherpad server when proper checks have been done and connect to one particular pad and this one only.

## security model
I understand that the current security model of etherpad lite is relying heavily on the communication being themselves secure i.e HTTPS, is that right ?
Given that HTTPS is an inherently broken system and can only provide at best casual eavesdropping protection but neither reliable authentication nor reliable encryption I was wondering the use of the "authentication token" :
>Authentication works via a token that is sent with each request as a post parameter
Is this really the way it works ? meaning the **same** token is passed in each request and thus if **any** client is compromised, **all* clients are ? or is there some client depending hash that is applied to the token ? I did not check the code and I am probably not proficient enough in js to do it right, so I am asking :)