>>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
>
>One possible solution I can imagine is that they must edit the XML file themselves and store the password encrypted. To do that you need to provide them with a small executable (or UI in your program) where they enter the connection credentials and the program then saves this with the password encrypted. So they can read and edit the information using that utility. Because you don't want to expose your secret key, create a second secret key for that purpose, just in case someone decompiles the utility.
>
>If they are security conscious, it might be a better option to use integrated security and handle the SQL server credentials in their Domain. This way you don't need to deal with the password.

Thank you for your input. Yes, I will create a separate small executable (setup) to allow the customer to change the password. So far, their security consciousness didn't reach the level beyond simply hiding the password in the XML file. So this will do.