>>>>>I guess that buying Chilkat would be a good move. I need a good encryption tool to encrypt fields
>>>>>
>>>>>The thing is that there are so many options in that Chilkat library that I'm wondering which function would be preferable to use.
>>>>>
>>>>>The data encrypted will have accentuated characters.
>>>>>
>>>>>What do you suggest?
>>>>
>>>>Denis, what are you trying to protect (physically what i.e. a DBF, a field in a DBF, etc), what is the value of the data (this goes to the lengths and costs you are prepared to accept), from who do you wish to achieve protection (end-users or experienced hackers)?
>>>>
>>>>In other words, unless you clearly to define what the encryption is for, and against who you need it, you may be chasing the wrong solution.
>>>
>>>Hi Jos,
>>>
>>>Protection is needed (encryption) because of the following possibilities.
>>>
>>>If an angry employee leaves one of my customers I don't want that person to have acces to the data of the enterprise.
>>>
>>>If someone copies the app from my client's computer I don't want that person to have an easy access to the data.
>>>
>>>So I guess that basic encryption would be enough.
>>
>>
>>1) How many sites are you talking about?
>>
>>2) How much time would coding field level encryption/decryption take i.e. this becomes a money question.
>>
>>3) How big is the data file that needs to be encrypted? i.e. the file that holds the sensitive data.
>
>Why those questions?
>
>Do you have something to suggest depinding on the answers given?
>
>Number of sites is not important. Customers need it and they will get it. Time needed shouldn't be that big a deal. It's just a small percentage of data that will be encrypted. Data is not very big.

If you want to be able to say to your customers, "disgruntled users can't steal your data" it's a good idea to be very clear what you can and cannot protect against. Otherwise you can expose yourself to legal liability.

Native VFP apps often consist of one or more executable(s) and data table(s) located either on the local workstation or a network file server. To be able to run such apps the users usually need at least read access to the EXEs and read/write access to the tables. With that level of access they can copy the EXE files and tables at any time. They can establish another environment elsewhere, copy in the EXEs and tables and run the app there.

Whether there is corporate-level/multi-site access control in place (Windows domain accounts etc.) or you have implemented your own user names/passwords/access control within your app does not matter. Suppose a disgruntled user is fired today and denied access to your app. If she has a copy from yesterday elsewhere, she has the same ability to use the data as before. Even if the data are encrypted she can still run reports such as "Print list of all customers" and easily extract information that way.

Security will also be breached if the user has access to any unencrypted backups (encryption in the backup software, not your app) and can restore from any of them.

Offering a false sense of security to your customers can be worse than offering no security at all.