We are encrypting our PDF with the following iText code. However, someone was able to edit our pdf (I am not sure how).
pdfWriter.setEncryption(null, null, PdfWriter.ALLOW_SCREENREADERS
| PdfWriter.ALLOW_COPY | PdfWriter.ALLOW_PRINTING,
PdfWriter.ENCRYPTION_AES_128);
Is there a better way for us to secure the pdf to prevent this?
PDF Encryption and restriction of information relies purely on the goodwill of the authors of the viewer software to enforce that restriction.
Generally speaking, every application that has enough information to display the PDF has enough information to print the PDF, there's nothing really you can do about it.
Since there are plenty of open-source PDF viewers out there, it's very easy to produce a viewer that simply ignores those restrictions.
See this explanation of the PDF encryption mechanism for more detail.
If your PDF is encrypted using 128 bits AES, then it is safe from someone that would not know the key, the most plausible explanation is that someone has had access to the key.
You may think about signing the PDF using RSA, that is a good way to make sure it has not been compromised.
Encryption which prevents the viewing of a pdf works if the password is long enough.
The DRM features which allow viewing but disable other features such as printing, editing,... only work if the reader co-operates. The user can use a hacked or third party reader to circumvent such restrictions.
Add a user password. It's the only one that really matters. As you have no doubt gathered from the other answers, the owner password is a bit of a joke.
The USER password is strong crypto... up to 256-bit AES IIRC, though the original PDF crypto spec only allowed for 40-bit encryption due to US export restrictions. Anything stronger than 40-bit was considered a "munition". Goofy laws.
The OWNER password is not, it's more courtesy than anything else. PDF libraries try to support it to one degree or another, but open source PDF libraries are a quick code change away from being "pdf crackers".
A blank user password means "use the predefined string of bytes listed in the PDF Specification that anyone can download". The contents of the PDF are still encrypted, but everyone knows the password, so it doesn't do you much good. PDF viewers/libraries substitute this string of bytes when given no password.
PS:
When calling setEncryption:
a null open password means "a blank password" as I described above
a null owner password means "generate a random one for me".
A random owner password means "no one can legitimately modify the PDF".. but that does not mean "no one can modify the PDF".
Related
I am able to extract text from PDF's which doesn't have any security restrictions. I just want to know if it is possible to extract text from PDF which has restrictions
UPDATE:
Thanks to all for your comments. I appreciate your concern. Please understand the question. I did not ask how to do it. I just want to know if it is possible. I have created a PDF with these restrictions. I do not want my information to be extracted from my document. There are many developers who can achieve any task. I want to know if this task can be done. If this can be done, then I will investigate further to overcome this issue.
As the OP clarified that he asked the question to know whether his documents with such restrictions are safe from text extraction, and that he does not ask how to do it (in spite of the explicit languages and libraries given in tags), here an answer on the principle option, not a concrete implementation. Thus...
Yes, it is possible to extract text from documents with restrictions as long as the document can be read at all and no other means are applied to prevent text extraction.
The restrictions you show merely are flags that indicate to a PDF processor what the author wants to allow or not to allow a user to do with his document but they are not technical restrictions.
These restrictions can only be applied to encrypted documents, but you surely want these restrictions to work in particular for anyone (other than you) who can open the document for reading, be it by knowing a specific user password or be it by using the empty password.
Cf. the specification ISO 32000 (here from part 2, similarly in part 1 with a focus on PDF viewers):
If a user attempts to open an encrypted document that has a user password, the PDF reader shall first try to authenticate the encrypted document using the padding string defined in 7.6.4.3, "File encryption key algorithm" (default user password):
If this authentication attempt is successful, the PDF reader may open, decrypt, render and otherwise provide access to the document.
If this authentication attempt fails, the interactive PDF processor should prompt for a password. Correctly supplying either password (owner or user password) should enable the user to gain access to the document.
Whether additional operations shall be allowed on a decrypted document depends on which password (if any) was supplied when the document was opened and on any access restrictions that were specified when the document was created:
Opening the document with the correct owner password should allow full (owner) access to the document. This unlimited access includes the ability to change the document’s passwords and access permissions.
Opening the document with the correct user password (or opening a document with the default password) should allow additional operations to be performed according to the user access permissions specified in the document’s encryption dictionary.
Access permissions shall be specified in the form of flags corresponding to the various operations and the set of operations to which they correspond shall depend on the security handler’s revision number (also stored in the encryption dictionary).
...
Once the document has been opened and decrypted successfully, a PDF reader technically has access to the entire contents of the document. There is nothing inherent in PDF encryption that enforces the document permissions specified in the encryption dictionary. PDF readers shall respect the intent of the document creator by restricting user access to an encrypted PDF file according to the permissions contained in the file.
(ISO 32000-2 section 7.6.4 Standard Security Handler)
Thus, these restrictions only work in cooperating PDF processors, but in particular in case of open source PDF libraries, it is trivial for a programmer to remove any code trying to enforce the restrictions.
Being aware of this, the developers of open source PDF libraries usually don't try to enforce the restrictions at all, or they add some flag to override restriction enforcement to prevent patched copies of the library to circulate.
I have the following three lines in my little game which store the id and pass of a new user:
Properties prop = new Properties();
prop.setProperty(id, pass);
prop.store(new FileOutputStream(new File("path/to/project/src/properties.data")), "");
Unfortunately I've noticed that only by changing the properties file extension to txt all the users and passwords become visible and readable by anybody, which is a thing I don't really like. Please let me know of a good easy method to encrypt the file in some way.
The thing is I already searched about this but the answers don't really fit my needs, I don't expect my game files getting attacked by the biggest hackers so using AES or any other big popular libraries would be too much I'd say. What do you think?
First, everybody can read your password file, no matter if the extension is .txt or .data or whatever else. The extension is just a Windows trick to decide with which program to open the file, but it does nothing to the contents.
If you want to encrypt the password file, you'll need a key and / or a password for that, and then you need to figure out where and how to store that. You just postpone the problem.
If the file holds names and passwords of the players in your game, go with #Boris the Spider's advice: instead of saving (encrypted) passwords, just save the password's hash. When someone logs in, calculate the hash of the entered password and compare that to the hash you have saved. If they are equal, the user entered the correct password. See this question and the accepted answer for a possible way to do this.
Here's an excellent article on storing passwords securely. The examples are in C#, not Java, but it's still a helpful discussion:
https://blog.mking.io/password-security-best-practices-with-examples-in-csharp/
I also strongly recommend the book "24 Deadly Sins of Software Security" by Michael Howard and David LeBlanc as a more general overview of common security bugs and how to avoid them.
I faced a similar problem and I took resort in writing an AES encrypted string in file (in my case, users were asked to take encrypted key from administrators to put into property files, so I provided a method to encrypt password to them too) and then decrypting it in the method where I am reading it.
I am developing an android application through which i am sending a mail via GMAIL API.
To send mail via GMAIL API i have to give them my ID and password.
GMailSender m = new GMailSender("myemailhere#gmail.com",
"mypasswordhere");
and i know writing password like this is not at all safe as my password could easily be stolen by extracting my apk and alsostoring the password in strings.xml is also not secure as xml can also retrieved.
my question is-
Is there any other way to write password in my file so that it remain secure??
The short answer is not. You shouldn't store your password anywhere in the code or in any file.
Even if you encrypt it like someone said you will have to store it's decryption algorithm/key somewhere in the code, which will be easily reverse engineered.
No,It's not safe to store passwords on the device.
small advice is always store passwords in char[] in encrypted form rather than storing in a String whenever it is mandatory to store.
Since Strings are immutable in Java if you store password as plain text it will be available in memory until Garbage collector clears it and since Strings are used in String pool for re-usability there is pretty high chance that it will be remain in memory for long duration, which pose a security threat. Since any one who has access to memory dump can find the password in clear text and that's another reason you should always use an encrypted password than plain text. Since Strings are immutable there is no way contents of Strings can be changed because any change will produce new String. So Storing password in character array clearly mitigates security risk of stealing password.
Storing passwords is not considered safe, and shouldn't be done if at all avoidable. There are a few considerations, if you have to for some reason.
The best place to store such things is in private SharedPreferences. These are not readable by anything but the app, or rooted devices. Do not store on external storage!!!
Encryption can always be undone, but if you have to, then it would be better than nothing, requiring more work to undo. Use a key which is unique to each device.
Some sort of a token, such as is used by Oauth, could be a solution. This isn't perfectly secure either, but it could be.
Google provides more secure APIs for it's functions. You really should look in to that.
I'm wondering if it is possible, using iText (that I used for signing) or other tools in Java, to add biometric data on a pdf.
I'll explain better: while signing on a sign tablet, I collect signature information like pen pressure, signing speed and so on. I'd like to store those informations (variables in java) togheter with the signature on the pdf. Obviously hidden and encrypted such as the signatures info.
Is there some kind of hidden data field on a pdf or something that can contain this kind of information? I think it is inappropriate to store it in the metadata fields such as author etc.
There are different ways to add info to a PDF document.
You could add the data in a document-level attachment. That way, people can inspect the data by opening the attachment panel.
Storing it as metadata is fine too, but you're right about it being inappropriate to store that info in something like the author key.
As you may know, the /Info dictionary will be deprecated in PDF 2.0 in favor of using an XMP metadata stream. In this metadata stream, you can add custom XML data (see section 2.2.1 of the XMP specification - Part 3).
If you don't want to mix your biometric data with the document metadata, you can even define an XMP stream for any dictionary you want, probably including the signature dictionary. See section 14.3.2 of ISO-32000-1.
PS 1: I don't know who downvoted your question. I upvoted it, so you're back at 0.
PS 2: If you want to create future proof signatures, read http://itextpdf.com/book/digitalsignatures
PS 3: Signatures created with the 4-year-old version of iText usually aren't future-proof.
With iText I can use Java to open a pdf and write it. If the pdf has an owner password I can still open it but it can not be written.
Clearly the content is readable, it seems like at that point you could simply write the document to a new file. iText doesn't allow this, it throws a bad password exception. Is there a way around this?
By removing the throw of BadPasswordException I was able to successfully save a pdf that had an owner password.
It sounds like the PDF is likely encrypted and has an owner password set but no user password set. If that's the case then iText is doing the right thing, since the owner password must be supplied in order to decrypt the file before you write the document to a new file (by contrast supplying just the user password, in this case nothing, will allow you to view the PDF and sometimes perform other operations on it like printing and copy/paste).
Most, if not all, well reputed toolkits are going to respect the encryption. However there are some less scrupulous tools out there that allow passwords to be "broken off." This is generally best avoided but such tools do exist.
The other option, assuming that the document's permissions have been set so that the user password allows printing, would be to print the PDF to a new PDF, either using a printer driver based conversion SDK (if you get a lot of these files) or by simply manually printing (if you only get them once in a blue moon). Printing a PDF to another PDF is a somewhat nsaty process because you then have to take care to manage instances of Acrobat, but can be done in a limited fashion if absolutely necessary.