>>Hi,
>>
>>I am sure I have multiple threads about encrypting a password. But this one is a new sub-topic (I believe).
>>
>>In my VFP 9 application the credentials to the SQL Server are stored in an XML file. The User Name and the Password. The XML has other settings but they are not important for this thread.
>>It has been working this way for many years for many customers and nobody has ever complained.
>>This year I have a new customer. They sent me an email this morning that the Security Officer noticed that the password in the XML file is clearly readable and changeable. So, they ask me to encrypt it.
>>
>>I can do it using the Cipher function (which is used in many other places of my app). But I won't share with them the Cipher key (string used in the Cipher function). Many internals of my app depend on this key. And I don't want to change the design of the application just for one customer. I explained to the customer (in the email) that if I do what they ask for, I will be the only person who will be able to change the password. Which puts them in a precarious situation if I ever go out of business or not available to maintain the app. I have not heard from them as to what they think about this scenario.
>>
>>Meanwhile I have a question. Is there a simple encryption (e.g. API function) in Windows 7 and 10 that I would use it to encrypt the password and call from the VFP 9 application to decrypt? If this were possible, they would be able to encrypt the password (in case it changes in the future) without my help.
>>
>>Again, I emphasize, I don't want to change the application in the way it reads the XML file. The only thing I willing to do, if possible, is to call some internal Windows function to decrypt the password.
>>
>>TIA
>
>Depending on what's required, you might be able to get away with a simple encryption -- for example something like a replacement cypher (i.e. aka "secret decoder ring" -- a simple 1-1 mapping where one character maps into another), bitwise XOR, bit-shifting, etc. To avoid situation with certain problematic character ranges (e.g. ASCII code 0..31, 127..255 -- the first range are control codes that have special meaning and are likely to get "mangled" if you edit with a text editor. The second set is prone to get "mangled" in double-byte character environment like in Chinese, Japanese and Korean as character codes often have special meaning and aren't considered "printable" alone), the encrypted text could be base64 encoded (that is if your encryption doesn't guarantee output in the narrow range of "printable" characters). To differentiate between the plaintext and encrypted values, you could use a fixed prefix for the encrypted value (e.g. anything starting with "*GAK*" could signify an encrypted value, where the actual encrypted data starts just after the "signature").
>So in a nutshell,:
>* establish a "signature" that your application would use to differentiate between plaintext and encrypted versions of the text
>* when you read the config file, if the "signature" is found, run the remaining text through decryption routine to get actual value
>* when writing out config file, make sure to prepend the "signature" to encrypted values
>* have a separate program that allows enduser to change the encrypted values within the config file

Thank you for your input.