How best to protect (DBF) Data

[Polly66]

Hi,

Does anyone know of a simple way to protect dbf files. After searching this Forum, it dosen't seem that there is. Cryptor by Hallogram has been mentioned to me, but I am of the opinion that this would be overkill. I only want to achieve a small degree of protection to deter inquistive minds.

Thanks for reading.

Bill Shepherd

 

[Mike Gagnon]

Put the data in a password protected drive (or folder).

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[alvechurchdata]

One simple-minded approach is to use a different extension. If you rename your dbf as "Customer.xls" and your index as "Customer.doc" then a casual meddler will be quite confused. The only giveaway is that the memo file will still be "Customer.Fpt".

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[JRB-Bldr]

As has been suggested above, there are a number of approaches which may depend on how "protected" you want your data to be.

Merely "to deter inquistive minds", but not REALLY encrypt the data itself, Geoff's suggestion of changing the data table names might be best.

I might suggest going even further than Geoff suggests in that any file containing a name like CUSTOMER, etc. might suggest the type of data contained within and further ignite user curiosity. Instead you might use some more generic file name such as GENERAL.123 to better deter user curiosity.

And, as Geoff has already suggested, using a different (non-standard) set of file extensions would prevent the inquisitive user from opening the file with the default application. Your VFP application will not care about the file extension of the data table (DBF file) as long as you specify it fully when you want to use it.

If you want to get somewhat more protection, you might consider encrypting only some of the field within the data table. Critical references such as Name, ID Number, Credit Card No., etc. might be encrypted while leaving other fields alone. There are a number of roll-your-own aproaches to field-level encryption as well as some already posted in this and other forums on the web.

The only problem with Mike's suggestion of putting the data into a protected file/folder is that the protection MIGHT get in the way of user access to the file under authorized use within the application itself. You would have to evaluate that for your own specific system.

Good Luck,
JRB-Bldr

 

[cconroy]

The way we protect our data, is to password protect the "data" folder, giving access to this folder to only one account. Then we use a 3rd party program (we use TQC, but i am sure there are others) that simulate the "run-as" function of Windows 2000 and above, to run our Visual Foxpro app using the credentials that have permission to the "data" folder.

 

[JRB-Bldr]

You also might want to look at: thread184-1115378

I might be considered among your "over-kill" approaches, but it is good protection.

Good Luck,
JRB-Bldr

 

[Mike Lewis]

I've usually found that a simple home-made encryption routine is all that's needed - and is better than relying on third-party products. Of course, it won't keep out knowledgeable hackers, but those folk have never been a threat in my applications. My main concern is to stop inquisitive users delving into things like password files.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[Stella740pl]

Take a look on these old threads, some of them have code with ideas you can borrow on how to implement some home-made encryption routine.

But as was already mentioned, renaming the table into something "system-like" looking, like General001.t13 or some random name like w8d45fg_x18b.s67 would deter "inquisitive minds" nicely. (The problem with random names, though, is to get used to working with them without confusing them yourself.)

thread184-862462
thread184-685479
thread184-547198
thread184-399660
thread184-27793

 

[JRB-Bldr]

Here is one solution to the issue Stella raised concerning The problem with random names, though, is to get used to working with them without confusing them yourself.

Use a General Reference table and a function to deal with the file name differences.

In that reference table you have 2 fields per record
1. IdealName
2. RealName

Then you can create a Function within your application which does something like the following:

* --- Used Wherever Needed Within the Application ---
=OpenTable("Customer")
SELECT Customer
  <do whatever>


* ------------------------------------------------
* Elsewhere, perhaps in your PROCEDURE file
*
FUNCTION OpenTable
PARAMETER lcAlias

* --- Open General DBF Reference Table ---
mcDBF = ADDBS(mcSystemDir) + "GENERAL000.123"
USE (mcDBF) IN 0 ALIAS ReferDBF

* --- Get 'Real' Table Name From Reference Table ---
SELECT ReferDBF
LOCATE FOR ALLTRIM(UPPER(ReferDBF.IdealName)) == UPPER(lcAlias)
mcRealDBF = ADDBS(mcSystemDir) + ALLTRIM(ReferDBF.RealName)

* --- Close Reference Table ---
SELECT ReferDBF
USE

* --- Open 'Real' Table Name Using "Ideal" Alias ---
IF !USED(lcAlias)
   USE (mcRealDBF) AGAIN IN 0 ALIAS (lcAlias)
ENDIF

* --- Return With Desired Table OPEN and Referenced By "Ideal" Alias ---
SELECT (lcAlias)
RETURN

Something like that would allow you to continue using the table refence names (a.k.a. Alias) that you desired and would allow the system to handle dealing with the "real" table names.

Good Luck,
JRB-Bldr

 

[JanBucek]

Another way is to ZIP character fields in tables. I use it usually to pack large MEMO-fields to achieve shorter FPT files. For shorter fields with fixed length is this way not effective, for ZIPped string could be longer than original one.
Disadvantage is of course the need to ZIP/UNZIP before every use of field and in all replace commands.

 

[Polly66]

Hi everyone, and thank you all for your most helpful comments. I think that I am going to have to think about this one for a bit, but the encryption of only one or two fields (thanks JRB-Bldr) could possibly be all that I need. Thanks again to all of you who responded to my request.

Kind regards
Bill Shepherd