I know of one organization that uses it to enable early release of a time-embargoed document to prevent server overload when it's released. Instead, everyone downloads the document in advance and they release the password at the release time.
If you're thinking about FIRST Robotics Competition, then yep that's nail-on-head about what they do. I briefly talked to one of the folks responsible for that system and they mentioned looking into using a CDN, but couldn't match the relatively low cost of serving a static file over HTTP elsewhere. That being said, the traffic is still enough to tank that entire Azure region last time I checked during the release window (other assets on the same host / their other hosts in the same region were incredibly slow to load.)
I hope you're joking but it is not over-engineering if you're the kind of organization important enough to have the need to release time-embargoed documents on regular basis.
Besides, he didn't suggest they bootstrap their own CDN. It could be as simple as creating a Cloudflare account.
Not joking. If the years have taught me anything that would be pragmatism. You want to introduce a new vendor and cost centre for what? Send your docs out early followed by a password if that's secure 'enough' for your use case.
Any further guesses as to how "important" the organisation is is pointless in the absence of understanding the actual use case.
Someone once explained to me that .pdf and Microsoft office encryption have the use case of 'someone benevolent gets the file by accident (browsing a network drive maybe) opens it, sees the password screen and knows they're not supposed to read it, and gives up.
It's more the equivalent of putting it in an envelope marked Private and Confidential than locking it in a box.
In many of these cases the password is in the email the file is sent with.
Your distinction is not meaningful. It's like saying that TLS isn't secured because one day someone may crack it. Everything is/was secure up until the point that it isn't/wasn't.
PDF, and Adobe in general are widely known to have a terrible security record. Relying on PDF encryption to keep your data safe isn't analogous whatsoever to relying on TLS. It's more like keeping your data on a Windows 98 machine, and then acting surprised when it inevitably gets cracked.
Tax information from govt, bank statements,credit card statements sent via email are all encrypted in India; although the passwords can be easily guessed from the information present in the email.
IMO, the primary benefit of encrypting pdf in email is stopping the email service provider from scrapping the pdf.
There are other better ways to accomplish that like lodging a document with a third party to ensure a lack of changes... regarding quoting... preventing text capture is a futile effort that really needs to stop existing - it's a pain to deal with and provides no real security since, much like snapchat - you can never counter someone taking a picture of the screen.
you can never counter someone taking a picture of the screen.
Except with digital watermarks. Photocopiers generally recognize things like currency and refuse to copy at high fidelity. The PS3 I believe would refuse to play ripped cinema soundtracks all the way through, using audio watermarking. It's conceivable that cameras could be required to do the same thing for digital restriction watermarks.
Even if they conspire with every camera manufacturer, they can't prevent someone from just retyping the text they want to quote. On a mechanical typewriter if necessary.
I guess they could try to do a denial of service attack on the typist by deliberately overusing letters from the same vertical keyboard row to wear out the finger.
Yes there are better ways but for a lot of small businesses those better ways simply do not get paid. It isn't how it should be and it will take a long time for things to change.
Ah okay, so you don't actually care about the selectability - just the immutability.
In that case a third party is the answer and has been the answer forever - if only the bank has a paper record of your mortgage then you have no guarantees they won't alter that contract on the sly - if it's lodged with a mutually trusted third party that doesn't have a vested interest with either participant then you're safe. The best I've ever seen with physical documents is a guarantee that the document hasn't been tampered with, but there isn't really a way to prove which document is the real document.
Basic integrated digital signature for documents is really nice. It can be used for DRM, but it is kind of a big deal for reports and other documents they need high integrity.
FIRST Robotics Competition used to distribute the rulebook for the season in an encrypted PDF. The password and unencrypted copies were released after the live kickoff stream. Ten years ago we'd be busting ass trying to crack the PDF but techniques weren't great then.
FRC was the thing I immediately thought about when I saw this (they still do PDF encryption), but the techniques here don't really apply.
I'm pretty sure that you could just try to brute force it, as the passwords as usually dictionary-based with substitutions (e.g. R0bot$InSp&ce).
Edit: After taking a much more in-depth look at it, all of the past game manuals' passwords are too complex to crack in a reasonable time (even with a dictionary). With a top 1000 word list dictionary with substitutions of 3-letter words like the above there are (conservatively) 1x10^20 combinations. You can't crack the PDF user key directly either, because recent game manuals use 256-bit AES keys.
I've always operated under the assumption that nothing in a PDF is secure, and that the only safe way to redact something from one is to print it and rescan it. Convince me otherwise?
I believe that if you edit the pdf so that the thing you are redacting is no longer in the pdf file, it is safely redacted. Printing a pdf and rescanning a pdf breaks text selection and screen readers, and basically makes it into a fancy PNG.
There is a bunch of data in PDFs that may have previously been visible but is no longer. I know that there are also fun meta-data attributes embedded on a per-page and per document basis - and also that PDFs can be portfolio documents where such a document will often contain no longer referenced PDFs that became irrelevant to the PDF. The file format is pretty crazy.
William Gibson, Neuromancer, 1984: "Data transfer from Bockris Systems GmbH, Frankfurt, advises, under coded transmission, that content of shipment is Kuang Grade Mark Eleven penetration program."
from the list, looks like preview.app/skim is the least affected... i wonder if that’s because it’s just lacking dynamic features of the others, or it’s just coded better, or it’s because macOS security defaults...
A company I was a contractor for would send payment invoices with a password. The password was the last four digits of the ID number specific to the contractor. Our CRM we all used had every contractors ID number in their profile publicly available. When I asked what the point was I was told upper management required a password and this was the easiest.
PSPDFKit CTO here. TL;DR on the PDFex vulnerability: The file format can carry both encrypted and unencrypted parts, which allows "injecting" malicious payload (embedded JavaScript, PDF forms that submit to remote URLs, etc) into an encrypted PDF that then can be used to exfiltrate the encrypted PDF parts, after the user decrypted the file (= entered the password).
We're currently investigating the vulnerability in detail and plan to ship an update ASAP that will allow our customers to mitigate it.
I'll be monitoring this thread to answer any questions.
spies! everywhere!
honestly, as someone who cares about typography and culture in print, the constant and relentless "spies everywhere" statements from the security community look more and more like a sickness, not a defense. PDF was designed for print integrity, with images and typesetting, and I am grateful for it everyday. Please calm your alarmist content, and yes, security is necessary.. a good servant and a bad master, I would say.
This tool likely only works for "passwordless" PDF encryption/protection, which restricts some aspect of using the document (printing, exporting single pages etc).
This is the domain of DRM/whitebox cryptography, and leaving aside all discussions about the feasibility of such efforts, PDF's implementation of it can safely be assumed to be broken – the master key used can be found in several open source PDF tools' source code and on Stack Overflow, among other places.
I assume the attacks presented in the paper are about the other type of PDF encryption, which requires a password to even display the protected content, which could definitely be done in a way not vulnerable to the attacks described.
The "master key" is just the empty password which means that the effective key is all padding. This is documented in section 7.6.3.3 of ISO 32000-1:2008 (available for free from Adobe's website). There was never any real attempt to keep it secret.
