Have you considered setting a password that expires at a predefined date/time?
A Google search for the phrase "encrypt file password expires at a predefined time" (without the quotes) turned up the following link:
Quick Crypt creates self-expiring encrypted files:
https://www.ghacks.net/2014/07/07/qu...crypted-files/
Quote:
Here you find several interesting options:
- Encrypt file using a system ID unique to the PC. Attempts to decrypt the file on other computer systems will result in errors even if the correct password is entered.
- Set a file expiration date. The file cannot be decrypted anymore once the expiration date is reached.
- Create a distributable zip file. This adds the Quick Crypt program and the encrypted file to a zip file for easy distribution since Quick Crypt is required to decrypt an archive.
|
FYI, I don't have any affiliation with, nor have I ever used, Quick Crypt.
However, reading the write up at the above link did spark some ideas.
I'm guessing the measures you decide to take ultimately depend on how important it is that your content be seen by intended viewers only and go nowhere from there.
That said, a few random thoughts --
Could a user get around an expired password simply by setting the date/time on a machine back to an older date/time? (For a lot of downloadable software the answer is actually yes.)
Some possibilities for dealing with that:
•
Could you create your own web-based content delivery system? I think it's possible (through scripting and various server settings) to create a non-public facing web page that displays content (an image) in a manner whereby: The user must login to view the content, the image cannot be downloaded by normal webbrowser behavior, and the page can only be viewed by an authenticated user n number of times and/or before a predefined date/time. Of course this comes with an obvious built-in weakness: The user who wants to can probably do a screen capture or use video recording software to record the pixels displayed on the monitor.(Although many mouse-keyboard combinations can trapped for via scripting. Whether or not you decide to go this route may depend on how much you trust your users.)
Basically, you send the user a link. Verify that the user has viewed the page. And take the page down afterwards.
•
Could you create your own client-based content delivery .exe file? Basically, you write your own source code (using whatever dev environment) and compile it as a downloadable .exe file which your user installs on a laptop or pc.
The user double clicks the .exe file to launch your app, logs into the app using a one time only password, and from there the app displays an image file (.bmp, .png, .jpg, etc.) that resides on your remote server (and not on the user's machine.)
And of course, when the user shuts down the app, code in the app's form_terminate() event (or equivalent) deletes (or scrambles) the .exe file itself... which short of extraordinary measures taken by your user pretty much ensures your user sees the content exactly once.
-jp
.
