Hi,

We're running a number of php scripting systems for managing various inventories. Data input and retrieval are done via web forms (with https plus user authentication).

Since the amount of data is small and the structures are simple (only arrays of strings & numbers), we've adopted an easier approach :

• no relational database backend on server,
• all data are stored as text .php files such that they can be loaded by invoking "require()" or "include()", and these files are owned by "nobody" (the httpd user) with mode "rw-------".

Recently our security auditor told us that the data in storage devices have to be encrypted in order to prevent information leakage in case the system is compromised.

Per-file encryption seems not quite feasible.

Could someone kindly suggest ways for achieving data leakage protection in our case ?

What kind of compromise do they want you to address, specifically? The mitigations are different for different cases.

Encrypting the whole partition protects against the contents getting accessed should the drive end up with a third party. The only realistice scenario there is when the drive is to be decommissioned and destroyed. The down side is that someone needs to enter the passphrase to mount the drive when booting.

Encrypting just the files still means that the scripts need access to the decrypted data. So if the risk is coming from the PHP scripts themselves, which is most likely, then that won't help even a little. Nor would partition encryption.

I expect that the security team will require you to use a database, once they discover that you didn't.

Your present scheme is never going to pass any sort of security-audit, anywhere, and encrypting the files won't help. It's "redesign time," padre. Your "too clever by half" design turns out to be not quite so clever, after all.

Did you think about what you posted? If you're storing all of your data in separate files, the only way to encrypt it IS to do 'per-file' encryption. And I cannot honestly see any reason, at all, ever, in 2017, to store web data in plain-text files. It is so trivially easy to hook PHP into MySQL or PostgreSQL, and just encrypt the database, that there is no reason to store plain text files.

Unless this is for a TINY system with one or two users, accessing just a couple of files....and if that is the case, your auditors need something better to do.

Turbocapitalist's first question is the place to start. What are you protecting against? The next question is to decide the level of protection you need. How vital is the information? If an unauthorized someone gets hold of the data will the world end, just your world or if the data were an hour old would it not matter? The answer to this question may make a big difference. I think sundialsvcs is correct that it is time to start from scratch and design the entire system properly. After you have been hacked is not the time to start. And the old saying is right: "If you don't have time to do it right the first time, where are you going to find time to redo it?" The other comments are right on target; encrypting databases is not difficult, using ssh to access them from remote hosts is not difficult. One other think to look into is Veracrypt or something similar as part of a solution, i.e. encrypting an entire partition or a directory. Defense in depth is, in my experience, the best approach

Turbocapitalist's first question is the place to start. What are you protecting against? The next question is to decide the level of protection you need. How vital is the information? If an unauthorized someone gets hold of the data will the world end, just your world or if the data were an hour old would it not matter? The answer to this question may make a big difference. I think sundialsvcs is correct that it is time to start from scratch and design the entire system properly. After you have been hacked is not the time to start. And the old saying is right: "If you don't have time to do it right the first time, where are you going to find time to redo it?" The other comments are right on target; encrypting databases is not difficult, using ssh to access them from remote hosts is not difficult. One other think to look into is Veracrypt or something similar possibly as part of a solution, i.e. encrypting an entire partition or a directory. Defense in depth is, in my experience, the best approach and need not be burdensome. Don't go overboard, but don't shortchange yourself either. One final comment: remember the process never stops. To begin with, Murphy is alive and well. On top of that, any security system devised by man can be defeated eventually by man. Present a moving target, not a static one. Continually review, and review, and review. There are always holes, it is just a matter of who finds them first. Once you have these things in mind I think you will find that security is not that difficult or onerous.

Sorry for the double post. The computer hiccupped and I didn't realize it at the time. Obviously it is the computer's fault.

Many thanks for all your comments & suggestions.

The criticisms by sundialsvcs & TB0ne are pointing to the real problem.

A few words on history. We started the development of the scripting systems in 2005, when data leakage was often overlooked, and simplicity in design was preferred. For scalability considerations, we've attempted to deploy PostgreSQL in 2011, but was abandoned prematurely.

Indeed the data are not critical, but the authority just want everything to be "compliant" with their standards.

As sundialsvcs had said, it's time to re-design.

For the choice of database, MySQL is the most popular recommendation, but SQLite attracts us by its simplicity.
We'd like to know if SQLite is a safe (in security sense) choice for use with php scripting ?

SQLite is a file. And, as such, it will run into the same security-auditor issues.

It is, however, a very, very good "file-based" database system, ideal for situations where you might otherwise use "a file." But it does have one very important proviso that you need to know about: "use transactions!" Even when reading. This is what allows SQLite to use buffering and "lazy writes." If you don't do this, it will immediately commit and then re-verify each and every write, and repeat every read, vastly degrading performance. (However, it is designed this way.)

Your auditors are looking for assurance that no one can "stumble upon" the data and have access to it without passing a security check and without the possibility of leaving an auditable trail.

Yet MariaDB/MySQL/PostgreSQL all produce files as well. So do tied hashes and BerkleyDB.

If you do go the route of the full SQL database, then the following might be of use:

https://mariadb.com/kb/en/library/da...st-encryption/

However, again I'd ask if you know specifically what threats the auditor wants you to address so you can prioritize them in your reworking of the database. It won't solve your auditor problem to do a lot of work on things the auditor doesn't understand or have an interest in. You don't have to tell us, but you do have to know them yourself so you can put them at the top of your list. They can ask for weird stupid stuff sometimes, not just common stuff or even established best practices.

Answering Turbocapitalist :
We're "told" to do so, and frankly we don't know what exactly are the auditors' concerns.
Possible motivations include a series of incidents in which the servers of some local companies were hacked, some had their files encrypted by ransomwares, and some had their notebook computers lost/stolen.

sundialsvcs's comments should be the one closest to the auditors' standpoint.
"Auditability" is the key difference.

Now there remains only one way for us : to run a true database server.

As mentioned before, we had some experience with PostgreSQL.
It's said to be an advanced tool, but is it good in terms of easy management & integration with php ?

You might consider getting those concerns enumerated in writing so as to avoid a long cycle of guessing and complaints that result in unnecessary expendature.

Then your auditors are doing a poor job. No one can fix problems unless they know what they are, so your company needs to get details from them.
PostgreSQL, MySQL/Mariadb are all good choices. Personally, I'd go with MySQL/MariaDB. Both can provide table-level encryption for a database:
https://mariadb.com/kb/en/library/da...les-to-encrypt
https://dev.mysql.com/doc/refman/5.7...ncryption.html

But before you go down that road, ask questions and think about what best fits the need. Your auditors don't seem to be the brightest lights in the harbor, if they can't tell you EXACTLY what they're looking for, why, and at least offer a small suggestion on how to correct it. If they're concerned about a data breach (and storing plain-text data in files that are web-accessible IS bad), putting that data in a database may be all you need to do. Because you can easily have the DB server only listen for/accept connections from ONE user on ONE server (say, your web server?)...and that may satisfy your audit requirements. Because in order to get unfettered database access, one would have to log in to the web server (and simple audit daemons can help there), break a password, then break the password for the DB user, THEN access the database. Lots of places to get mired and give you opportunity to catch them.

Of course, many database-servers store their databases "in files." But the essential difference is: who has access to those files?

Like dBase, Paradox, Clipper, and "all those other systems of yore" (that are very-much still in service!), SQLite stores its data in a file which c-l-i-e-n-t-s access directly. True "database servers" do not: only "the server, itself," has access to the underlying files (if any ...), and users of those servers are prevented from having direct access to them.

An auditor's legitimate concern is: "Can I steal this database?" Can I stick it on a thumb-drive, run away with it, and thereafter do with it as I may please?" With all filesystem-based topologies, such as all of those listed in the preceding paragraph, this is a very-legitimate concern.

1 members found this post helpful.

I'm quite sure that your auditors would accept either MySQL or Postgres ... among others.

When evaluating the two systems, realize that they come from two very-different design philosophies (and histories), with comparative strengths and weaknesses that need to be "compared" in reference to your(!) application. Both are venerable, industrial-strength systems ... but ... "they are different, that's all." Take the time to consider those differences carefully in reference to your application. Over these many years I have worked with many successful and secure projects which were based on both of these technologies. One is not "inferior to" the other. "They are different, that's all."

For instance, Postgres has a formal concept of storing "an object." It also uses a different strategy for providing "repeatable read" transactions which allows for more concurrency.

If you do select MySQL, be sure to use InnoDB, not "MyISAM," tables.

1 members found this post helpful.

Thank you all for your valuable advices.

We'll revise our data storage, and deploy a suitable database server.