Edit this page on GitHub


docassemble is designed with user privacy in mind.

Security features

Server-side information storage

User passwords and interview answers are stored in a SQL database in encrypted form, unless the multi_user variable is set to True, 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 the 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.

security

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 security issues in a Javascript library. The installation of npm may have security implications. However, the only Javascript-based application that docassemble uses is azure-storage-cmd, and this is only used when Azure blob storage is enabled.