In a project I am working on, I needed to write some cron job scripts, which purpose is, to access some external API's, which have information that shouldn't be accessible by the public. The external APIs all require a username and password to make them accessible.

The client was concerned, that if somehow, someone, manages to hack the server, and we store the passwords in the script files for these API's, the hacker would gain access to the secure information, or could transfer out money from these API's to his own account.

To resolve this problem, basically, to make a second security layer on the whole application, I tought that I could eliminate the cron jobs, by writing a simple daemon application, which when started, asks for a password from the administrator. With that password, he decrypts the API access keys, and starts replicating the things that the cron jobs did before.

The biggest drawback to this, is that whenever the daemon stops for any reason, an administrator MUST restart it manually, but my client said that this is not a problem for him.

Basically, what I would like to know, is, how safe is this approach? Can a hacker, who manages to hack into the server, retrieve the admin password which was provided to the daemon when starting, from the memory?

The environment I use is PHP (I know that this is not the best solution to daemon scripts, but time is of concern, and this was the fastest to implement).

What other drawbacks does this method has, that I haven't thinked about?

2 Answers 2


Moving the password to memory does raise the cost to the attacker, but not by a lot - and in exchange, the server process does indeed become more fragile (requiring human presence to restart), which (as you pointed out) may adversely impact SLAs.

The general rule is that if a legitimate process has access the information, so does the threat actor (if they gain access to the legitimate process's environment). Any API that is implemented in this way requires the plaintext password.

It may take some work to educate your client to understand this.

(That's the basic answer to your explicit question. Here is some additional information about the larger problem you are trying to solve:)

Another mitigation might be to store some of the material in an HSM. If implemented properly, this would make it even harder to access. But even then, if the server is compromised, an attacker could write additional code to intercept the password as it is being sent to the API.

Another option is to move the password to a more secure proxy server. If you don't have the ability to lock down the current server, but you could create another server that you could make significantly more secure, then you could use that server as a proxy, and store the password there. This increases complexity, but might be worth the tradeoff if the proxy server can be more hardened. That proxy server could also be used to monitor the transactions for unusual activity, and block any that do not meet certain criteria.

You could also work with the API provider to limit where the activity is coming from to specific IP addresses (so that the threat actor cannot just steal the password and then use it from anywhere).

If the server side supported it, you could also use public-key encryption to protect the password, or a client SSL certificate to control who can connect via TLS.

And in general, you should be using HTTPS for the connection, and using POST instead of GET to prevent the password from showing up in URLs in logs, etc. This will help protect the password in flight outside of the server.

But in all of these scenarios, the password must be used in plain text - and will always be vulnerable to interception at some step in the workflow.


One concept that I often try to articulate to clients is the clean source principle. It can be very effective if you assume a breach of a system and work from there, but also requires that you understand the trust relationship between the systems and their elements. This can be more complex than many people imagine.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .