From aa3fb3c746bf7f9e2cdbde75dd563f1e326106d0 Mon Sep 17 00:00:00 2001
From: Thomas Waldmann <tw@waldmann-edv.de>
Date: Fri, 4 Oct 2013 00:28:28 +0200
Subject: [PATCH] add security documentation

---
 docs/index.rst    |  1 +
 docs/security.rst | 77 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 78 insertions(+)
 create mode 100644 docs/security.rst

diff --git a/docs/index.rst b/docs/index.rst
index f90cda4..6c51b39 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -12,6 +12,7 @@ Welcome to nsupdate.info's documentation!
    intro
    user
    admin
+   security
 
 
 Indices and tables
diff --git a/docs/security.rst b/docs/security.rst
new file mode 100644
index 0000000..d7e45e1
--- /dev/null
+++ b/docs/security.rst
@@ -0,0 +1,77 @@
+=======================
+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).
+
+
+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).
+
+
+CSRF protection
+===============
+
+We use Django's CSRF protection middleware.
+
+
+XSS protection
+==============
+
+Django's templating engine html-escapes inputs by default.