Public Notebooks and Security
tl;dr: don’t disable notebook authentication!
Let’s chat a little bit about public Jupyter notebook servers and security. A lot of folks run notebook servers that are publicly accessible, whether they are the access point to a cloud server or remote access to their home or office computer. This is great! It is important to keep in mind that, since arbitrary code execution is the main point of IPython and Jupyter, running a publicly accessible server without authentication or encryption is a very bad idea indeed. Prior to notebook 4.3, this was the default behavior of Jupyter, which has led to a lot of insecure notebook servers running on cloud services. One aspect that may not be apparent is that people can find your public notebook server, especially if it is on one of the popular cloud providers. Systematic port scans will turn up notebook servers, especially for those running on the default port of 8888. And Jupyter has become popular enough (🎉) that we know people are doing this (😠). Running a publicly accessible notebook server without authentication is making your computing resources free for the world to use.
The highlights to keep in mind:
- Always enable a password or token for publicly accessible notebook servers (this includes shared computers)
- Use HTTPS for authenticated notebooks over the Internet
- Unsecured public notebook servers are discoverable
- Running on a cloud service should be treated as if it’s publicly accessible
The first two points shouldn’t be new information, and anyone following the documentation should be adding basic authentication when exposing a server to the public. If you are already accessing a notebook server over https with a password or token, you have nothing to worry about. However, if you are running unsecured notebook servers on the Internet, please stop and enable a password. The latter points are important and may not be obvious, but the gist is: don’t disable notebook authentication, even if you think your bases are covered via other means.
In notebook 4.3, a token is enabled by default, making it a little bit more inconvenient to run a totally insecure notebook server. We can’t feasibly require HTTPS by default, but free, trusted HTTPS has never been easier, thanks to LetsEncrypt. If you can’t assign a domain name to your server, self-signed certificates can be used, with some caveats (notably: Safari requires self-signed certificates be trusted at the system level before it will allow websocket connections). For shared deployments, you can also use JupyterHub, which allows you to authenticate notebooks via the system (PAM) or OAuth providers such as GitHub, Google, etc.
Be safe out there.