Hi,
The only way I can think of to overcome this problem is to not have keyboard input for passwords, as they can quite easily be trapped.
The use of a graphical screen keyboard which sends vectors of screen clicks instead of characters, and the vectors are scrambled by a predefined algorithm, then sent to the FLL or whatever where they are unscrambled and translated.

The password is store as vectors in the file, and when they are retrieved they are unscrambled by their own separate algorithm not the one used for the challenge and then and only then the comparison this done, preferrably not as the original as entered password.

>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.