How secure is the mivadata directory?

[wmgilligan]

I am not using nor referring to the merchdb.dat file or Miva Merchant. But you bring up a good point...

[AHerb]

and... stop using FTP, go for SFTP
Default FTP uses unencrypted passwords to connect.

[ILoveHostasaurus]

Thanks Jonathon, Hostasaurus. In my case, no stores involved - strictly MivaScript. I am assuming the PA-DSS would encrypt because anyone with FTP access could get that file. But if FTP access is limited, then no real need to encrypt?

My concern is not so much a person getting ftp access (very limited in the situation I am looking at), but rather someone hacking via the web, etc - and getting access to it.

You can check the PA-DSS page in the store admin and it will tell you if your database credentials are encrypted. If you have not changed your database password in a while and/or it was ever used by any other applications, or it had been stored unencrypted for some period of time, no harm in changing it. You can replace it, or the encrypted text for it, in the merchdb.dat file and change it on the database server at the same time. Then, in the store admin, run the PA-DSS wizard from the PA-DSS page and you can choose to let it re-encrypt the merchdb.dat file, which will use the current encryption standards.

Generally, Miva Merchant is run under an Empresa running as the user associated with the site, and PHP apps often are run the same way, so it's important the merchdb.dat be encrypted because a hacked php app could potentially read into the miva data directory and/or that file if there aren't other restrictions in place on where the php app can get to.

[Rick Wilson]

Anything that can be uniquely identified or triangulated to a person, so an email for sure, as well as Name, Address Phone number among other things. Err on the side of caution if you're unsure.

[wmgilligan]

This brings up an interesting aspect. What is considered PII? Is it simply credit card info, or is the email of a customer? What about the name and physical address of where an order is going, or billed? For the record - I am not looking at storing this info, I am just curious as to what should be encrypted both in the mivadata directory, and elsewhere. We all understand that credit card data must be, and SS#, and the like must be. But what about a file in this directory (or a field in a database) that lists a name and address? Is my Contact List on my local MAC encrypted? Should it be? If I stored that file in the mivadatadir, should it be? If I put that info in a database for later use on another computer - should it be? At what point is PII no really Personally Identifiable Info?

[Rick Wilson]

It all depends on what data you're talking about storing in there. Anything that's personally identifiable data (such as customer order data) should be encrypted.

[wmgilligan]

Thanks Jonathon, Hostasaurus. In my case, no stores involved - strictly MivaScript. I am assuming the PA-DSS would encrypt because anyone with FTP access could get that file. But if FTP access is limited, then no real need to encrypt?

My concern is not so much a person getting ftp access (very limited in the situation I am looking at), but rather someone hacking via the web, etc - and getting access to it.

[ILoveHostasaurus]

The proper security setup should be Empresa running as CGI or FastCGI, under suexec or equivalent so it is executing as the user associated with the website in question. Then, mivadata, and all directories contained within it, should be permissions 700, and all files contained within it should be 600. Typically the only thing of any real importance in it will be the merchdb.dat file which contains the database credentials the store uses to talk to its database. Those should be encrypted, but if they're not, the store's PA-DSS wizard can be run which will re-encrypt them. Of slightly lesser importance, but not something to be overlooked, would be any leftover export or import files left under the mivadata/Merchant5/s01/export/ or upload directories from past imports or exports, which may contain customer data (but not payment data unless something very bad was done via third party module). Those should be looked for and cleaned periodically.

[Jonathan-Driftwood]

Very. Apache (and the public) cannot reach it publicly; only Empresa can. Its very handy that way and one of the stellar elements of Miva Empresa which keeps me coming back year after year. Only reason (for me) to encrypt anything in the /mivadata folder would be to protect it from FTP access - IF the ftp server app allows access to that folder.

[wmgilligan]

Just curious - how safe is the mivadata directory considered?
The one I am asking about is located outside the html directory, so not accesible via the web.
But - is it considered secure? What is safe to be stored there? Should everything be encrypted?