78 lines
2.5 KiB
ReStructuredText
78 lines
2.5 KiB
ReStructuredText
|
=======================
|
||
|
|
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.
|