In case your FLL simply returns a True or False, then yes I understand Jos's concern.

There is an encryption method that will encrypt the original string and decrypt if sent the encrypted string. In that case, this algorithm could be used to check whether the FLL is not merely an interceptor.

key  = 'sdfdfgdgdfg'
a1   = 'sdfsdf'
a2   = routine( a1, key )
a3   = routine( a2, key )
okay = ( a1 == a3 ) and not ( a1 == a2 )

In case this would be considered overactivity if done for each instance of encryption, it could be done on init, merely to check whether we're dealing here with the right FLL. A third parameter could be the instruction to the FLL for this mode.



>Good question Jos. Yes, this is definitely possible. There was a thread on this somewhere on Tek-Tips awhile back... I can't recall off-hand what the suggestions were for doing this. One thing that a developer could do to secure their application against this type of hack is to generate a message digest (hash) for the FLL they distribute, then hard code a check against this in their app. If hashfile == whatever then go ahead, if not then warn user and tell them to contact developer immediately (or something along those lines).
>
>What would be interesting is a way that this type of security (protection against the hack you outline) could be built into the FLL itself. Anyone have any ideas on how to accomplish this? Another potential security hole is that a key will usually exist somewhere in the application code... without using certificates (public key encryption) it is difficult to store this securely in the app or even externally... so the other question would be what's a good way to shore this security hole up? Christof showed a way to obfuscate passwords/keys in an advisor article one time by making the code as confusing as possible... however I keep thinking that there must be a better approach to this... maybe not as simple, but more secure.
>
>>Hi Craig
>>
>>iro your VFP encryption library - because one needs to pass the password to the encryption/decryption routines would an attacker not find it quite easy to substiute their own dll/fll for yours and then intercept the password when the routines get called? Is this a possibility for attack? If so, is there a way around this perhaps by setting up the password in the main app and the dll/fll looking for it under a static variable name or something like that? Or do you feel this an unlikely scenario?
>>
>>Thanks.