Hi all,

I am going to respond to Tamar's reply, even though others have contributed their suggestions, because her suggestion is closest to what I might implement. I will give an overview first to bring everyone up to speed. Before I start, the client has said they are not willing to invest in any new tools at this point - won't go into detail why, just saying that to say I need to improve this with just VFP code.

Oveview:
- table records are encrypted for sensitive data i.e. not all fields, just ones like birthdate etc.
- the key used is a 3 part key where the first 2 parts of the key are built into the app but the last part is unique to the record
- this key is then used to encrypt strings via the wwEncryption class in WestWind tools which calls .Net encryption functions

What the customer wants:
- not a commercial product, customer just asking me how safe is the data in the tables (VFP tables, not backend tables) if they had a breach and the tables were exfiltrated
- I have said "really safe" up to this point until I realized that since the first 2 parts of the key (split up, one in an obfuscated config table, the other in an app property) are the same for the whole app, with only the last 5 characters being unique to each record; now I am thinking it would be too easy to guess how the key is made up (i.e. the last 5-6 characters are the primary key for each record). If someone was looking at the table and then was stopping the process on each call to wwEncryption/.Net, they would see that the last 5-6 characters of the key match the primary key of each record

But the customer does not want to buy Refox or have me figure out how to recompile it in the new VFP engine as they are within a year of switching to an entirely new backend with encryption done in another manner.

So my thought is to do 2 things:

1) stop using the primary key as the unique part of the encryption key; I will use something else non-sequential and not obvious when browsing a table

2) Tamar suggested wrapping the key compilation in an expression instead of working it up first and then passing it to wwEncryption/.Net e.g. instead of doing this like I have:

lcKey = app.FunkyFirstPartOfKeyFromProperty + GetAppFromConfigTable("FunkySecondPartOfKey") + tcUniquePartOfKey

lcEncryptedData = owwEncryption.Encrypt(lcDataString, lcKey)

*instead, pass the components of the key as 2nd parameter in the call:

lcEncryptedData = owwEncryption.Enrypt(lcDataString, app.FunkyFirstPartOfKeyFromProperty + GetAppFromConfigTable("FunkySecondPartOfKey") + tcUniquePartOfKey)

so that the compiled key never exists as a var in VFP before making the call to wwEncryption

Questions:
a) so does that help with hiding how the key is compiled since they will only see the compiled result if they can read it when the wwEncryption function fires

b) does it help to put the key compilation code inside a protected property (that has a _access method) in VFP or does that do nothing more than just having the code in the main program (as the debugger can see code inside of a protected property just the same as code anywhere else).

Thanks all for any further comments.

Albert


>This is way outside my wheelhouse, too, but one thing I did when I needed to hide a key in code was never assemble into a single variable. I passed an expression into the encryption routine that was built on the fly.
>
>Tamar