Data security

Visual FoxPro tables are not secure. The facts are simple: users and people with evil intentions can open a DBF using a number of products via ODBC (using the VFP ODBC driver), or OLE DB (using the VFP 7/8 OLE DB provider), or by products that read the Visual FoxPro DBF format directly.

One basic security measure we have heard developers implement is to make a stored procedure call from a table rule that looks for a PUBLIC memory variable. If the memory variable does not exist, the rule fails and the data cannot be updated. Your application can create the variable so it is always in scope and the stored procedures will work. Outsiders who access the data will still be able to read it, but not update it. If they know what they are doing and have a copy of Visual FoxPro they can edit the stored procedure directly and remove the check, so this approach is not foolproof. It has always been our belief that it is the user ‚ s data and they have the right to access their information any way they see fit. We can only protect them so much without limiting the things they can do with the data, especially with ad hoc reporting needs and IT departments supporting internal processes that might not be included in the applications you provide to your customers.

You can take a similar approach with DBC Events using Visual FoxPro 7 or higher. DBC Events allow you to write code that executes before tables are opened, before a table or view can be modified, created, or dropped, and several other actions you might want to control. Returning a .F. from these events stops the action from taking place. Incorporating the PUBLIC memory variable technique, you can stop all actions handled by the DBC Events. Unfortunately, if users are smart and have a copy of Visual FoxPro, they can open the database, turn off DBC Events, and disable your security measures. It is not foolproof, but it is easy to implement and works for non-sophisticated customers.

Remember ‚  

Selecting Database Events for a database container does alter the database so prior versions of Visual FoxPro cannot access the database (or the tables contained therein). If your solutions include VFP 5 or 6 applications accessing the same data as a VFP 7, 8, or 9 applications, you can not use this technique.

One thing we do recommend is encrypting columns with sensitive data. Employee salaries, employee identification numbers, credit card numbers , medical information (a big issue for developers writing applications in the United States with Health Insurance Portability and Accountability Act (HIPAA) regulations), passwords, and other personal information that in the wrong hands can trigger legal problems you and your customers want to avoid. There are encryption products such as Cryptor from Xitech (Europe) ( http://www.xitecheurope.co.uk ) that encrypt Visual FoxPro tables on the hard drive, encrypt during writes , and decrypt when reading. Using a product like this slows access to the data, but provides complete security of the information.

When we have data security issues of any sort , we recommend moving to a backend SQL database with native security supported at the engine level instead of having to write code to work around this deficiency. You know anything you can write code to secure can be just as easily reverse-engineered by another developer.