HOW TO ENCRYPT AND MANAGE PASSWORDS OF PDF's THAT ARE FOR SALE ON WEB

It's possible to use third-party tools on the webserver to add a unique password to a copy of the file, that is then downloaded to the user - but not using Acrobat, and not with the latest rich media PDFs. Your website will have to handle all the login and access tasks, but adding an open password to a basic PDF is easy to do with PHP or Java - search these forums for info on what's available.

It's impossible to restrict the number of printouts, or the ability to copy the file. Even DRM can't do that.

Actually it is easy for users to decrypt your password using PDF password Remover or recovery.Open password or owner password no longer works well for protection. I suugest you take another way, how about downloading the file using personla email and firstly ask for puchase and then allowing download?

Back to the original question of selling PDF's over the web...

I am try to produce a PDF that I wish to sell annual subscriptions too.
Demo's could be downloaded providing restricted functionality, but a
A subscription code (similar to what Microsoft or Adobe uses) ie: 1234-ABCD-5678-0123-1234
would open up the functions and restrict it to 24 months of operability.

Is there a best way to do this?
Or do the PW crackers Apps all defeat this functionality?

That type of limited-use access is not possible with a PDF, even with digital rights management you only have basic yes/no control over things like printing, copying and form-filling. You cannot for example hide specific pages or content based on a license key.

To put a time limit on the file itself (so you can revoke access completely) requires use of Adobe LiveCycle policy server. The other option would be to publish your documents in non-PDF format and secure them through a service such as Adobe Digital Editions, but any server-based solution of course carries a large setup and running cost, so it's only economical if you're selling masses of files, or charging very high prices.

But could you not have sections hidden and have these visible based on the Subscription key or validation code?

I was hoping to use a subscription key or form variables (with a start date, another having form approved or not). Then have the form initiation script process against these variables to validate.
Displaying the appropriate form data or a NOT Valid watermark or text field if fails...

But to do so, I would need the security to not allow users to change the subscription key or form variables or validation code....

But from what you are saying, the above is not very secure

A other suggestions?

The security applied by DRM solutions such as LiveCycle is at document level, and must be applied through a policy before the PDF is sent to your recipient. LC allows access to a document to be revoked, but you cannot change access to specific parts of a document on-the-fly, and all the changes have to be made by you, through the DRM server - each document is assigned to a recipient via their login details (username/password) on the server, not by a license key or password.

The only realistic PDF-based solution to your workflow will be to issue two different files: the demo with parts actually removed, and the full version after they've paid. Turning one into the other is impossible, and to put any form of time limit on the file will require use of LiveCycle policy server. If you're selling a few a day, doing it manually through LC's interface is not too hard, but automating the process and linking it to a website shopping cart etc is a major development job, and will have correspondingly high costs.

It all depends on how much you're tied to PDF as a format - if for example you convert the contents into Flash/AIR applications, running a licensing system would be far easier to implement yourself as the document becomes an installable program. PDF is far more useful to the customer, but when you bring in DRM security it does mean that the PDF has to be opened via Adobe Reader, so it cuts out people using iDevices, cellphones, etc.

Many thanks for the input