Given that you say "exe programs" and MSSQL, I assume this is Windows? In that case, you can use DPAPI (the Data Protection API) to encrypt (and decrypt) passwords (or other sensitive data) in a way where the OS handles the key management and ciphers for you. You'd call CryptProtectData
(or one of its variants) and store the result in a file or in the DB, then read the encrypted secret back out and call CryptUnprotectData
to get the password back when you need it. You could also use encrypting file system (though that isn't available on Home editions of Windows) or use the Credential Vault (which is just DPAPI + data storage in a single API).
Mind you, I don't know if there are PHP bindings for those APIs. Legacy DPAPI and modern CNG DPAPI, setting the Encrypt flag on a file, and accessing the credential vault, are C APIs. There are bindings for them in .NET and many other languages/frameworks, though, so probably there's already a PHP wrapper for them.
Note that none of these options are truly that secure. The keys used for DPAPI and EFS are protected by the password of the account in question. If you run the webserver as a passwordless service account, then the keys aren't really protected; anybody with admin access (or physical access to an unencrypted drive) can extract them. If there's a password on the account but the service manager supplies it automatically, admins or those with direct drive access can extract the password from the service definition. In both cases, the threat model is the same as if you just stored the password in a file that was only readable by the web server; it just requires more steps for the attacker, not actually more secrets or access.
If the web server runs in your user session then DPAPI/Vault/EFS uses your own password for protection, but so does everything else running under your account and if there's any malicious code it can just call CryptUnprotectData
on the encrypted blob, or use debug APIs to read the secret out of the server memory. Still, if you don't run any malicious code (at least, not under your own account), this approach would at least protect your app password from attackers while your account isn't logged in (unless they can guess or brute-force your password).
Fundamentally, no option is going to let you securely store a secret in a way that some code running on your machine can access, but no other code can, unless the accessing code (the web app/server) can be given a secret that no other code can use... which just kicks the can up the road. Might as well require that the password be supplied to the server when it starts, then, and avoid storing it at all. There's no silver bullet for secret management; it's secrets (usually encryption keys) all the way down. If you want to start some code automatically without needing to supply a secret, then that code fundamentally can't protect data in a way that somebody else - also without the secret - can't break.