Storing Credentials for Secured Resources?

diverman asks: "It is very common for web applications (be them Java, Perl, PHP, .NET, or shell script) to need knowledge about credentials to access another resource. Perhaps it's a relational database login, an FTP account for transferring files, or maybe a authentication credentials to another web service. Whatever it is, most developers have likely had to write a program that needs to keep a password for later use. The big issue now is: where do you put them?" "Having passwords sitting around in clear-text isn't the wisest of ideas, and is against most security 'best practice' guidelines. Some apps and servers have chosen to base64 encode it (I believe WebSphere does this), and that's about as safe as clear-text. What I've been trying to find is a mechanism that behaves like how Apache loads properly signed SSL certs, that require a password when starting up the web server. The password could be used to decrypt a key-store for various application/resource credentials, and then make them available. Exact implementation isn't the question, as much as ANYTHING that does this at all. Are there any Apache modules that can place authentication information in ENV variables for executed apps, after decrypting them on server startup? Are there ways to have Java containers do something similar? It seems like this is something that is a very common problem, but not a very common question, with an even less common solution."

Comments

autoboot vs secure passwords

[vanyel]

You either have to store passwords on the system in a way that programs can get to them, which no matter what you do, is insecure, or you have to have someone there whenever the system reboots. And if you've got a vhost server with hundreds or thousands of domains hosted...

There are two solutions I can think of off hand:

1. If the application allows, make the database or other sensitive resources append-only by the basic app. Further access requires the user to login with higher level credentials.

2. Have some sort of media with "read-once" properties; when the system is rebooted (which typically triggers a reset of some sort), the read-once is reset. The necessary connection parameters can be stored here then.

Use a keypair and agent

[linuxkrn]

I do this on my servers without using passwords. What I have is a keypair (ssh) that has a very long (256+ chars) passphrase. Then I have a ssh-agent running on the box. Each bash script then sources a file I create in ~/.ssh/my-agent.env that sets $SSH_AGENT_PID and $SSH_AUTH_SOCK.

Whenever the agent doesn't have a key added, I can just do ssh-add, then enter my passphrase and it is stored in the agent. When I exit, that agent is left running and all scripts then source the env to get to the PID/Sock for my agent.

This works for shell scripts, but you could use it in other areas too with some code. So even if someone stole the keypair, the would have to brute force the passphrase to use it. And no passwords are kept in my scripts.

Only requirement is you add a key as soon as you reboot the box or your scripts don't work. A simple ssh-add -l will show keys and you can have the scripts exit/email error if no keys are added to the agent.