PDF Passwords and Permissions
Is a PDF with a password safe? It depends on which password and on what you expect of it. A PDF can have a user password, which encrypts it, and a master password, which protects a set of permissions for printing, copying and editing. Only the first keeps anyone out; the permissions are instructions to PDF readers. Here you find what each setting protects and what your Windows Forms application has to take care of when it opens PDF documents of others and creates encrypted ones.
How to set the passwords and permissions when saving is shown in Passwords and Access Permissions.
What Each Setting Protects
Three properties of the save settings protect a PDF, and they apply to PDF documents only:
| Setting | Protects | Doesn't protect |
|---|---|---|
| UserPassword | The content: the PDF is encrypted and opens only with the password | Against changes by those who know it |
| MasterPassword | The permissions: only readers who know it can change them | The content: it doesn't encrypt anything by itself |
| SaveSettings.DocumentAccessPermissions | What compliant readers let users do after opening | Anything, unless a MasterPassword is set as well |
The reference gives the encryption key length as 128 bits; Encryption TX Text Control Can Open shows how Adobe Acrobat reports it.
Where Permissions Stop
Text Control's articles on PDF security draw the same line:
- Permissions aren't encryption. Compliant PDF readers such as Adobe Acrobat respect them, but they aren't a cryptographic boundary, and other readers can ignore them. Once a user can open and decrypt a document, the permissions depend on the reader.
- Encryption protects confidentiality. Content that must stay confidential needs a user password. Permissions are best used as a policy on top of it.
- The master password lifts the restrictions. A reader who opens the document with it gets all permissions. Text Control recommends different values for the user password and the master password, so that readers who may open the document can't change its permissions.
- Neither password shows changes. Encryption doesn't prove that a document is unchanged or who created it. A digital signature does; Certificate and Private Key Handling covers the key that creates it.
Respect the Permissions of a PDF
When your application loads an encrypted PDF, TX Text Control decrypts it, but it doesn't enforce the permissions of the document. The application is responsible for getting the password from the user, for retrying when Load throws a FilterException with the reason InvalidPassword, and for carrying LoadSettings.DocumentAccessPermissions over to the DocumentPermissions of the editor. Otherwise a user who may only print a PDF can edit and copy it in your application. Open a Password-Protected PDF and Apply the Permissions in the Editor show the code. Documents encrypted with AES and a 256-bit key or with certificates can't be opened at all, as Encrypted PDF Documents lists.
Check That a PDF Is Encrypted
In an automated process, a missing password in the save settings leaves a document unprotected without any error. Check each file your application creates: loading it without a password must fail with the reason InvalidPassword. Check That a PDF Is Encrypted shows the check with a ServerTextControl.
Next Steps
- Passwords and Access Permissions: save PDF documents with passwords and permissions.
- Certificate and Private Key Handling: sign PDF documents so that changes can be detected.
- Handling Untrusted Documents: the other checks for documents from outside.
- The blog article PDF Security for C# Developers: Encryption and Permissions in .NET: the permission values and how PDF readers show them.