Securing PDF Documents with Passwords

2/11/2014 By Marco Kesseler 0 comments

PDF files can be secured with a user password and an owner password. In a way these passwords are very related, as they both control the level of access that you have on a document. But there are some differences, and we sometimes get questions about these, in particular what it means for encryption.

In principle, the use of these passwords is rather straightforward:

  • The user password is needed to access a document at all. If a user password has been specified, you will not be able to open the document without providing this password. So typically, you will set such a password if you intend a document to be read by one specific person, or group, that knows the password.
  • The owner password controls the document restrictions. You will find these restrictions if you open the Document Properties of a document in Adobe Reader (ctrl-D) and select the Security tab. Amongst others it is possible to restrict printing of the document, or copying of content. Adobe Acrobat will not allow you to change the document restrictions without providing the owner password. The owner password however, does not restrict opening or viewing of a document.


In real life, we hardly encounter documents with a user password. PDF is mostly used for distributing information and the least that you normally want people to be able to do is to open a document and view it. So if you encounter a secured document, chances are that is has only specified an owner password.

Note that if a document has a user password, you will not be able to ignore this, because all readers will prompt you for it upon opening:



As soon as one sets one of these password, the PDF document will be encrypted. This sometimes gives rise to confusion, because there is software that is able to remove the document restrictions -controlled by the owner password – without providing this password. PDFKit.NET is able to do this, as well as some other software packages.

Adobe Acrobat on the other hand does not allow you to do his. It will always require you to provide the owner password in order to change the permissions. There are 2 aspects that need to be considered here.

  • Technically, there is an important difference between the role of the user password and the role of the owner password during encryption. In essence, only the user password plays a role in computing the encryption key. Without the correct user password the PDF file cannot be decrypted, and thus it cannot be viewed at all. If only an owner password is provided however, the file will still get encrypted, but in that case the encryption key will be computed from an number of other properties of the file itself, so in essence the encryption key is no secret then. This means that if no user password has been specified, anyone can decrypt the file, which is effectively as good as no encryption at all.
  • The owner password is meant as a lock on the document restrictions, but as it plays no role in encryption this is merely a convention. This comes as no surprise: if the owner password had played a role in encryption, it would have become impossible to open the document without providing it. So technically, there really is no way to secure the document restrictions better than by convention.

Users that set the document restrictions, need to be aware that technically there is no obstruction against removing these without providing the owner password, although many software applications will restrict this by convention.

TallComponents software

One of the questions you may have now, is why our software does not play by these conventions? The answer is actually quite simple: we do not provide end-user applications, but merely tools for building them, and there is no way that we can effectively enforce these conventions.

Take PDFRasterizer.NET for example. It provides methods for drawing PDF pages to a System.Drawing.Graphics instance. There is no way however that our software is able to control how the result will be used. It could be used for viewing, but also for printing. So if some printing restrictions are set in the document, it is up to the final application to deal with this. Our software cannot control this.

For PDFKit.NET the situation is similar, although less apparent at first sight. PDFKit.Net allows you to remove the Security settings of a document without providing the owner password. We could have made an API that only allows this when a correct owner password gets passed. This however would only seemingly have solved the issue. For even with the security settings intact it would still have been possible to create an unsecured copy of this document using all sorts of other API calls in PDFKit.NET. API calls that also can be used to do things that are allowed for a secured document.

This means that dealing with these document restrictions is not something that our software components can, or should enforce. It is up to the application developer to make sure that these conventions are met. And it is up to the creators of these PDF documents to be aware that the document restrictions cannot be enforced technically.