4

I need to store credentials on my private root server in order to run some automated tasks like file transfer from remote servers via sftp etc. I might use shell scripting or maybe php to run those automated tasks, triggered by a cron job.

Now I have to make sure nobody breaking into my server will be able to read the stored credentials. My first thought was to simply encrypt the data and decrypt it on the fly when it is needed. But then I will have the same problem with the key: It has to be stored somewhere on the server. Thus an invader will be able to find the key and use it to decrypt the credentials anyway.

Is there a pattern or a standard solution for this kind of problem?

AvL
  • 151
  • 5
  • 4
    [Hardware security modules](https://en.wikipedia.org/wiki/Hardware_security_module). – SEJPM Oct 01 '15 at 17:19
  • I think this is more something for the security site (then again, I just answered a crypto question on that site). – Maarten Bodewes Oct 01 '15 at 18:03
  • @MaartenBodewes Oh, I didn't know there was the security site – any moderator is welcome to migrate the question! –  Oct 01 '15 at 19:15
  • 1
    @SEJPM HSMs are still vulnerable to physical access - while you can't (normally) extract a key from an HSM, nothing prevents you from using the HSM in place and decrypting the sensitive data that way. – André Borie Oct 02 '15 at 04:25
  • For SSH-based services, do not use passwords. Use e.g. public key auth and store the private key somewhere secure and accessible only to the dedicated user connecting via SSH. Besides HSMs, you could mount a ramdisk and copy the key there from local after you boot up the system. And/or you could secure your public key with a passphrase and use ssh-agent in background so you only enter the passphrase once until restart. Those approaches will require manual intervention once after bootup though. You could also use some PAM with SSH for other solutions like 2-factor e.g. with SMS. – Arc Oct 02 '15 at 16:05

2 Answers2

6

What you're asking for is impossible. If the server can decrypt the data, so can an attacker with physical access to the device. Before thinking about strong crypto, think about strong physical security. Hosting companies aren't what I would call strong security.

If you're merely concerned about defending against malicious root access, then an HSM will prevent them from stealing the keys for later reuse, but they'll still be able to use them while they have access to the server.

André Borie
  • 12,706
  • 3
  • 39
  • 76
  • That is what I assumed… I guess I have to think about a totally different setup! – AvL Oct 02 '15 at 08:01
0

This question has many potential answers, ranging from loose at one end to paranoid at the other.

The two most important things to consider in almost all security related implementation questions are:

  1. How important is the data you're trying to protect?
  2. How motivated are your attackers likely to be?

In this case, if your attacker isn't a highly competent, motivated individual a reasonable solution would be:

  1. Encrypt the login credentials you're using for SFTP (username + password) with a passphrase and store them somewhere on the disk
  2. Rather than using cron, use some kind of long running daemon to do your periodic tasks. When you first start this process, read the encrypted credentials off the disk and enter the passphrase manually (in a shell)
  3. The decrypted credentials will remain in the memory of the process for its lifetime (you'll need to re enter the password for the credentials when the process is restarted). While it's possible, it's non trivial for an attacker to dump the memory for the entire process and trawl through it until they found the decrypted credentials.

While this solution is not impenetrable, it makes it at least difficult enough that an attacker managing to read arbitrary files off the disk wouldn't be able to gain access to unencrypted credentials, and even someone will full access to the server would have a reasonable degree of difficulty.

Nic Barker
  • 1,170
  • 7
  • 11