add security documentation

docs/index.rst

@@ -12,6 +12,7 @@ Welcome to nsupdate.info's documentation!
    intro
    user
    admin
+   security
 
 
 Indices and tables

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.