Hi Cindy,

>Ultimately, the key has to be hard-coded or stored in a table somewhere doesn't it? And doesn't it have to stay the same for each field throughout the whole time the app is used? Or, did you cycle the encryption key and REPLACE ALL with a decrypt/re-crypt from time to time?
>
>All suggestions welcome!


You ~can~ hard code a key, or store the key in a table somewhere, but the key itself can be encrypted or otherwise obscured.


Here are some other possibilities for the key value.

1. Use some string that is always obtainable but changes from installation to installation (of the app). For instance, if you record a Client/Customer licensing code [or client/customer name itself], you could use that for a key.

2. You could use a CustomerId field [or any other character value in the record] as the key for a customer name field. This would give you a different key for each customer record.

3. You could put an encrypted value in a table and have cipher decrypt it with itself as the password, and use the end result as the key for the rest of the system. For instance:

A value in an obscure table in a field named Reserved1: %#@*GDNLED&*#$
lcKey = DECRYPT(Reserved1,Reserved1)


If you use your imagination you could come up with other possibilities.


I would add that the CIPHER encryption library, although extremely fast and easy to use, is not incredibly difficult to crack if someone with decent 'cracking' skills is determined to get at your data. It does not compare to more modern implementations such as the Windows Crypto API or other encryption schemes that are available.

But it does a very good job of keeping sensitive data from the average corporate snooper.

Guy