How to protect your credentials from malicious PHP code

Do things old school with pen and paper only. Total web protection is never a guarantee. But at least follow the owasp guidelines.

@jlrdw No, you have to have the credentials to do something like access your payment processor. Take the example of running stripe or braintree, so you have your key/secret pair in your credentials file. For example the .env file. What's to stop some malicious composer package you installed from reading that .env file and sending the credentials to an outside source. I'm talking about this level of protection. I'd like people's thoughts on patterns.

First of all and this comes from the author not me the dot environment file shouldn't even be used in a production environment only for development, but if you do make sure it's not in HTDOCS or public, but above so it will be safe from viewing. @Snapey showed a while back how this can be viewed very easily if not properly set up. And only go with known good composer packages, the open source software you use is entirely up to you.

What's to stop some malicious composer package you installed from reading that .env file and sending the credentials to an outside source.

Nothing, and thats why you should be careful with the packages that you pull in.

@d3xt3r see we are bound to agree sometimes.

Sure, but what if you're writing a platform, that allows plugins. And it's used by your customers. What kind of guarantee can you give them? What if a trusted package you thought was secure, had their github hacked? You thought it was secure, not it isn't. Wordpress is a perfect example. Allows the use of plugins, but plugins can be a entry point due to exploits. How can you make your precious configuration files with credentials more secure?

look to what the mobile phone manufacturers are doing such as a secure enclave within the kernel of the application. All keys etc would be encrypted at rest and only unencrypted when the particular application provides the correct identity and key. This would be very hard to secure though since the component itself can be easily reverse engineered and spoofed. The answer to this would be code signed service providers. Probably impossible to implement without a framework and ecosystem designed with this as a design goal from the start.

@Snapey That's a good thought and a valid response. Signing php code can be done with PHAR. So if composer utilized phar for all packages with code signing, that would be a interesting design. Look at http://www.robpeck.com/2015/07/securely-signing-php-phar-files-with-openssl/#.V4ABJJODFBc for more information on signing PHAR archives. This would protect against tampered with composer packages and dependencies. That's a decent approach, as long as you know the 3rd party author is "trusted".

So, good on that response. What if PHAR is not an option?

And just remember hackers are also great programmers so no matter what it is always hard to stay one step ahead. That's why in my first post I referred you to owasp. Likewise if you're writing something that contains secure information please do not go with a off the shelf thing like WordPress roll up your sleeves be secure and write your own code or use an approved known good vendor.

https://wordpress.org/support/topic/can-wordpress-plugins-contain-malicious-code

On the same lines develop an anti-malware for your users, if you allow them to install external 3rd party plugins and if you really want to go to those heights.

Funny thing about open-source, its open, if you stick to the implementation by core framework developer and their trusted plugin, I will say you are almost safe. And may be the reason why no framework takes 100% guarantee for 3rd party plugins.

Extra requirements need extra measures.