Protect Files

[reemcs]

Hello all,

 

This is my first topic .. Please Help me

 

The question is:

I Have a website and I am using PHP The employees use my website to upload their documents (PDF files). These files will be stored in the server.

 

Now how can I protect the PDF files in the server from developers ?  I don't want developers (even me) to open the files from the server if they want to see the files they can login into the system and see the files (if they have the permission).

 

I want when I click on the file (in the folder) I can't open it!

 

Do you think serialization (object) will solve this problem? 

 

Is there a technique similar to encryption can solve my problem?

[Psycho]

There are many options, but the best approach depends on many factors from what control you have to the business needs. Here are a few options:

 

1. Store the files on a drive location that is encrypted and which the developers do not have direct access. This requires that you have control of the server/environment. You could just store them in a location that the developers don't have access to, but not encrypted, depending on the significance of the data.

 

2. Create a process such that when files are uploaded they are encrypted before stored on the drive. The encryption key can be unique and random for each file to increase the entropy. So, no one would be able to 'open' a file without decrypting it first. If someone had the actual flat-files, they would still need the encryption key. Access to the database should be strictly controlled as well.

 

3. Store the files in the database - and encrypt them.

 

 

Note, that no "encryption" method is 100%. Given enough time and processing power anything can be cracked. So, if you were to just encrypt the flat files, if someone could access those files, they could copy them off to try and brute force decrypt them.

[Jacques1]

No offense, but the stated goal is very naïve and simply impossible. You cannot protect the files and at the same time prevent yourself from breaking that protection – unless you have some kind of split personality. And I hope the serialization stuff was just a joke? Serialization has nothing whatsoever to do with security.

 

So what do you really want? A bit of handwaving to create the illusion of security and maybe scare off a few kids? Or do you want actual security?

 

If you just want to do some handwaving, I'll leave this topic to somebody else. If you want security, you'll need a realistic scenario, actual cryptography and a lot more knowledge than you currently have. In a nutshell, there are two basic scenarios:

• The users trust you to encrypt their files. This provides maximum usability, but it means that you and anybody with sufficient rights can access the plaintext data at any time. In fact, the users can't even tell if there's any encryption at all.
• The users encrypt the files themselves before they upload them (e. g. with GnuPG). This provides maximum security and indeed prevents you and your developers from accessing the data, but it's fairly inconvenient and requires a certain level of technical understanding (which the average user may not have).

If you go with server-side encryption (the first option), install a good high-level library like libsodium, generate a single random key and store it in some configuration file outside of the document root. Then protect the files with authenticated encryption (this provides both secrecy and integrity).

 

Theoretically, it's also possible to implement password-based encryption where the users “unlock” the files with their own password. But this is very complex and doesn't necessarily increase security, so I'd go with a single server key.

Edited January 19, 2016 by Jacques1

[Psycho]

No offense, but the stated goal is very naïve and simply impossible. You cannot protect the files and at the same time prevent yourself from breaking that protection – unless you have some kind of split personality.

 

I agree with the rest of your last post, but as for this part, it is not necessarily true. My organization hosts applications that deal with data which has very stringent legal requirements for data access. We have a deployment organization that is responsible for the maintenance of the environments and the deployment of new releases. Even in that organization there are only a handful of people that have access to the databases and secured files in those environments. Developers do not have access to the production environments and there are very detailed processes and auditing for them to request data when troubleshooting issues. Even though a developer would know how to decrypt a file, they wouldn't have access to it.

 

This is by no means fool-proof, a developer could work with a deployment engineer to get the data out of normal processes or a deployment engineer could try to get the source code or just brute force the encryption. My point is that securing sensitive files from developers is a valid (and sometimes legal) requirement.

[Jacques1]

I think you're arguing against a statement which nobody made.

 

Of course you can and should limit access to the files, which includes strict policies for employees. But the OP said that he has a website and now wants to prevent himself as well as all developers from accessing the files. This is nonsensical. If the encryption happens server-side, then anybody with sufficient rights (the site owner, admins, high-ranking developers) can subvert it, and it's very important to realize that. 

 

My point is: Before you write security-related code, you need to understand what you're protecting from whom. I don't think we're there yet. All I see is “Please give me some PHP magic to throw at the files, maybe it'll help.”

 

 

 

This is by no means fool-proof, a developer could work with a deployment engineer to get the data out of normal processes or a deployment engineer could try to get the source code or just brute force the encryption.

 

“Brute-force the encryption”? What do you mean by that? Modern cryptography with sufficiently long keys cannot be broken by brute-force, which is really the whole point. If yours can be, there's a fundamental problem with your implementation.