1

I am building a small application for a real estate company which needs to store sensitive information such as bank statements, tax returns, etc. Right now i have the upload form as just a standard html upload form using php $_FILES to move the file to the desired folder. This works fine but there is no level of security to protect this sensitive information. I have two questions?

First, what is best practice (as of 2017) for storing sensitive documents like bank statements, tax returns, etc? I have tried to search for best practices online but everything im finding is 5-10 years old information or deprecated php functions. Is there specific php function I should be using/researching?

Second, are there any tutorials or books available that would help me understand secure file storage, file encryption, etc., in php?

My ultimate goal is just to make sure these files are secure and don't fall into the wrong hands. My question is specific to file uploads. I do understand that the rest of my site has to be secure as well. My question is simply about protecting files.

Thanks for any help or guidance.

user982853
  • 2,470
  • 14
  • 55
  • 82
  • I'm not sure would it be a good idea to use BLOB.Since you can add it to the database where you could do some crypting magic. – DaAmidza May 24 '17 at 16:37
  • It will be slower tho...But could do the job thats for sure – DaAmidza May 24 '17 at 16:37
  • 1
    Encrypt your content with public key (and probably just store in the database, the "how" part isn't really important, unless we are talking about PDF or other large files) and keep the private key in an air-gapped system. – tereško May 24 '17 at 16:40
  • @tereško Hi :D So blob could be the solution for it? – DaAmidza May 24 '17 at 16:40
  • and to use MyISAM of course.. – DaAmidza May 24 '17 at 16:41
  • 1
    @tereško These would definitely by large PDFs. We are talking 20-50 page tax returns, etc. – user982853 May 24 '17 at 16:41
  • 2
    Then I would encrypt the files and store them on the filesystem. Your main focus would be to make sure, that just because your server gets hacked and DB dumped, there is no way actually use any of it (hence, the [air gap](https://en.wikipedia.org/wiki/Air_gap_(networking))). – tereško May 24 '17 at 16:44
  • May i ask what file-types will you support? –  May 24 '17 at 16:45
  • PDF is the most common for these types of documents but also the common image types like jpeg and gif. @tereško if your are recommending files for larger files, do you have any documentation or references for how to encrypt the files? Thats my question. I don't mind files or blob, i just need to be able to make them secure. If files is the way to go, then how to i make them secure. "encrypt them" doesn't help me much as my next question to that would be "how is that done" lol. Im new. Thanks for your help. – user982853 May 24 '17 at 18:21
  • It doesn't matter whether it is 2017 (the same principles that were used 20 years ago also apply today) or that you're using PHP or what kind of sensitive documents you want to secure. You need to think about who *really* needs to access those documents and whether you can move them somewhere it is not directly accessible from the internet (and I'm not talking about an additional hop to the database server, but rather a whole segregated and firewalled network). – Artjom B. May 24 '17 at 19:28

1 Answers1

2

First, what is best practice (as of 2017) for storing sensitive documents like bank statements, tax returns, etc?

The literal answer to this is simply to keep them ENTIRELY OFFINE (on a remote hard disk, if needing to keep them digital at all) and store them in a good quality safe with only one -or maximum two- verifiable keyholder(s).

  • Read https://security.stackexchange.com
  • Read https://crypto.stackexchange.com

  • Read, download and use the Defuse PHP Encryption Library. My reading up on the same topic last year persistently showed this library (and all of Defuses stuff) was very high if not market leading in this arena. This encryption library can en/decrypt files.

  • Also research Halite. Which is a High-level cryptography interface powered by libsodium, which can encrypt and decrypt files.

  • Also please read my answer here for MySQL best practise for securing data storage (string or blobs etc.).

  • If using a database it is paramount that the database and the file server are different servers (and depending on the value of your data they should be in very different physical locations), and the database contains an encrypted key needed for the fileserver decryption, so that if when one server is compromised, the data is still secured.

  • Use your own server(s). Don't use the "cloud". (To have proper online data security is not really cheap)

Martin
  • 22,212
  • 11
  • 70
  • 132
  • I really don't agree with keeping these records non-digital. You're just changing electronic security for physical security which is usually not that much better. It's just that you simply reduce the number of people who can find a physical weakness. But such a move severely restrict the possibility of doing business in 2017. It's just not practical anymore. – Artjom B. May 24 '17 at 19:33
  • @ArtjomB. It was a literal answer to the *literal* question, there was no scope as to knowing who *needed* access to the documents, and if it's sensative information then keeping it **offline** will be safer, as referenced by comments answering the question, stating using air-gapped media, few things are better "air gapped" than a safe. – Martin May 24 '17 at 19:55
  • @ArtjomB. I also fundamentally disagree that physical security is usually not that much better than digital security. You make sweeping assumptions..... – Martin May 24 '17 at 20:43
  • 1
    Libsodium itself doesn't do files, but [Halite](https://github.com/paragonie/halite) does. (Defuse's File encryption library was my main contribution, and was modeled after what Halite already did.) – Scott Arciszewski May 29 '17 at 06:21
  • 1
    @ScottArciszewski thanks for the info, I have updated my answer! – Martin May 29 '17 at 10:24