docassemble is designed with user privacy in mind.
User passwords and interview answers are stored in a SQL database in
encrypted form, unless the
multi_user variable is set to
in which case the answers are not encrypted.
If users log in with external authentication methods or the
phone login feature, interview answers are still encrypted (unless
multi_user variable is set to
True), but a resourceful
hacker could figure out the encryption key. Therefore, if server-side
encryption is important to you, it is recommended that you do not
enable external authentication methods or the phone login feature.
Uploaded and assembled documents are stored on the server (and on Amazon S3, if S3 is being used, or Microsoft Azure, if Azure blob storage is being used) without encryption. These documents cannot be accessed from the internet without an appropriate access key in the cookie.
When a user clicks an “Exit” button, docassemble will delete all of the information related to the interview from the server, including the database, uploaded documents, and assembled documents. However, temporary files in /tmp will persist until cleaned out by a cron job.
docassemble blocks brute-force password-guessing attacks.
docassemble also supports two-factor authentication.
By default, users do not need to verify their e-mail addresses, but
you can require them to do so. See the documentation for the
email confirmation privileges configuration directive.
Importance of using HTTPS
It is important for security purposes to deploy docassemble using HTTPS rather than HTTP. If you use HTTP, passwords and security keys will be sent over the network in plain text.
Separate development and production servers
Users with “developer” access can run arbitrary code on the server. For this reason, it is recommended that you not allow developer accounts on production servers, and that you only install docassemble add-on packages that you have carefully reviewed.
Issues to look out for
docassemble makes extensive use of eval and exec, including to process information supplied by the user. There are protections in place to prevent code injection, but more work could be done to harden docassemble against such threats.
The options for allowing users to log in with Google, Facebook, Twitter, Azure, and mobile phone numbers are provided for convenience, but you may wish not to enable these features because the encryption of interview answers on the server is less effective when users log in without a password. This is because the password is used as the encryption key, which is advantageous because it is not stored anywhere on the server; the user remembers it and it is stored in a cookie in the user’s browser. When users log in with something other than a password, however, there is no such key available. As a result, the key for encrypting user answers on the server is constructed based on information that is stored on the server. As a result, an intruder with access to the server could reverse-engineer the encrpytion key for an interview belonging to a user who logs in with something other than a password.
On Docker, docassemble installs npm from a different source
because npm is missing from Debian stretch due to unresolved
application that docassemble uses is
this is only used when Azure blob storage is enabled.