nsupdate.info/docs/security.rst

=======================
Security considerations
=======================

Transmission security
=====================

Use https for the web interface as well as for the update client (if possible).

Otherwise, your username / password (FQDN / update secret) will be transmitted
in clear text (unencrypted).

The web interface will warn you if you use it via http. If WE_HAVE_SSL is
set to True, it will suggest you better use the https site and link there.

Additionally, the service administrator can implement a redirect from the
http to the https site within the webserver configuration for the WWW_HOST.
The redirect should **not** be implemented for WWW_IPV4_HOST and WWW_IPV6_HOST
as it is unknown whether all update clients can deal with a redirect.

For the router / update client configuration examples we show when creating a
update secret, we use update URLs with https: (and we also tell why it might
not work).

On the hosts overview page, we show whether we received the last update via SSL.


Passwords / Secrets / Keys
==========================

Interactive login password
--------------------------

We recommend that you use a rather strong and not guessable password for this.
Do not re-use passwords, use a password system or a password manager.

The interactive login password for the web site is stored using Django's
default hasher mechanism, which is currently pbkdf2 (a very strong and
intentionally slow password hash). Brute-Force attacks against such hashes are
very slow, much slower than against simple hashes like (s)sha1/sha256 etc.

It is NOT stored in clear text by nsupdate.info.

If you lose the password, you'll have to do a password reset via e-mail.


Automated update secret
-----------------------

The automated update secret for routers or other update clients is a
random and automatically generated secret. We store it using the sha1 hasher
of Django (which in fact is salted-sha1, a not very strong, but fast-to-compute
hash).

Considering that a lot of routers or update clients store this secret in clear
text in their configuration and often transmit it using unencrypted http (and
not https), this secret is not too safe anyway. We also wanted to save some cpu
cycles here and rather not use pbkdf2 for this regularly and automatically used
secret.

It is not stored in clear text by nsupdate.info.

If you lose the secret, you'll have to generate a new one and change it in your
update client also.


Nameserver Update Key (backend, RFC 2136)
-----------------------------------------

We currently store this key (which is basically a base64 encoded shared secret)
"as is".

This is somehow critical, but also hard to do better - encryption would only
help very little here as we would need to decrypt the update key before using it,
so we would need the unlocked key of that encryption mechanism on the same machine.

Make sure no unauthorized person gets that key or he/she will be able to update
ANY record in the respective zone / nameserver directly (without going over
nsupdate.info software / service).

We support creating random update keys, so you don't need an extra tool for this.


CSRF protection
===============

We use Django's CSRF protection middleware.


XSS protection
==============

Django's templating engine html-escapes inputs by default.


Cookies
=======

The software ("as is") uses these cookies:

* "csrftoken" (host-only, for CSRF protection)
* "sessionid" (host-only, to keep the session when you have logged-in to the
  web interface)

If you have set WE_HAVE_SSL to True (because you run the software on a https
site), you should also set *_COOKIE_SECURE to True to avoid the cookies getting
transmitted via http.

Be careful with domain cookies
------------------------------

The software ("as is") does not use any domain cookies.

In case you modify the software, please be extremely cautious with domain
cookies and in case of doubt, do rather not use them.

If you use domain cookies (like for ".yourservice.net", the leading dot
makes it a domain cookie), all hosts in that domain would be able to read
and write these cookies. Your site (at e.g. www.yourservice.net), but also
users' sites (like attacker.yourservice.net).

Obviously, this might lead to security issues with stealing, modifying and
faking domain cookies.


Sessions
========

We use Django's more safe JSONSerializer to serialize session data.
For Django >=1.5.3, the serializer is configurable.
For Django >=1.6 json will be the default rather than the less safe pickle format.


Django's SECRET_KEY
===================

Well, it needs to be secret, so don't just keep the value from our settings.py,
but define a really secret one in your local_settings.py.