>Unless forced by gov regulation or customer, don't.
>While the .dbf is partially encrypted, this wiil stop ONLY those trying to read in the .dbf via Excel or similar stuff.
>Someone determined to get your data will hook your program and get access of all info within minutes.
>Hardening the vfp exe needs more than Refox - if you went to vfp C++ compiler, table encryption might nake sense-
>
>Otherwise depend on customer IT to block all areas except Windows-encrypted ones for the groups using your stuff.
>If done well gives you better security, if botched: not your fault ;-)))
>
>
>>I only need to encrypt a few fields within the entire application - do not need a rewrite of the entire app into SQL server etc. The customer just has a few "sensitive" fields that they would like encrypted.
>>
>>I have read about Craig Boyd's vfpencryption71.fll and it seems to wrap to all the current encryption standards (correct me if I am wrong) but his blog stops in 2010 so not sure if there are any newly found bugs in this dll that might not be fixed. I have also looked at Rick Strahl's class (which I have) which wraps .net functions and encrypts with TripleDES - in this case, not sure yet if this is secure enough (no guidance from the customer and I just don't know enough about encryption to make the reccommendation).
>>
>>Are there any other classes etc out there that provide the AES256 encryption mechanisms?
>>
>>Again, just want to replace the contents of a few fields with an encrypted value.
>>
>>Thanks,
>>Albert

I had often wished that Windows had something similar to setuid in *nix where program will automatically execute with credentials of the owner (yes, I know there is RunAs -- but you'll need to type in the password. With setuid no password prompt is presented). With such a setup you can set the attributes of the data directories and files to be only accessible by the owner of the executable. Of course such a scheme isn't without some problems -- one obvious one involves spawned child processes.
Of course, moving away from DBFs to something like SQL server would probably give you better results than having something like setuid.