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

Most?!?

[NevarMore]

"Having passwords sitting around in clear-text isn't the wisest of ideas, and is against most security 'best practice' guidelines."

MOST?!?

Which security guidlines say it is ok and what companies are using them?

Re:Most?!?

[swillden]

Which security guidlines say it is ok and what companies are using them?

Companies that build real security systems often intentionally store on-disk passwords in cleartext, just to make the point that on-disk passwords are inherently insecure -- no matter how you obfuscate them -- and to encourage the use of hardware security modules.

Re:Most?!?

[swillden]

Personally, I consider El-Gamal to be encryption rather than "obfuscation", and quite happily store authentication token ciphertext in mysql.

And where do you store the decryption key? It's still just obfuscation, no matter how good the cipher is, as long as the attacker can get the key.

Don't use passwords

[forsetti]

Passwords are for "Authentication". Your user has already been authenticated. You are now looking for "Identity Forwarding" or "Identity Session Management". Do not use passwords are your Identity Token. Look at technologies like Kerberos, which use your password for authentication, give you a identity token in the form of a TGT (Ticket Granting Ticket), and then allow you to request unique (and optionally forwardable) tokens for each service you are looking to access.

In the web world, CAS provides proxy tickets, which can even be forwarded (for example, to an FTP server) as a stand-in for passwords via PAM.

Re:Don't use passwords

[swillden]

Your user has already been authenticated. You are now looking for "Identity Forwarding" or "Identity Session Management".

Sometimes. In other cases, what you want to do is to authenticate the server that is making the request. The user's identity isn't relevant, and that user may not even have any privileges to use the protected service directly. Instead, the "front end" service cares about who the user is and is willing to make some requests of the back-end service on the user's behalf, so it's actually the front-end service you want to authenticate to the back-end service.

The scenario you describe also makes sense, and also happens, but it's not the only situation that needs to be addressed.

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.

Obvious?

[Ahnteis]

Plain text. On my desktop. Named "sensitive passwords.txt".

I'll trade a paper version for a candy bar. :)

I am your users!

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.

It's easy.

[Pig Hogger]

You write it encoded with a super secret reel (found in all package of Admiral Crunch Hacker Cereals) down on a piece of banana paper using cherry juice so it is only visible when you heat it with a hemp flame, then fold it in 64 and tie it up with a piece of wire, put it in a tiny ziplock bag, dip it in sealing wax and put it in a film canister, which you dip in tar, then wrap it securely in wax paper.

Put it into a tiny sample jar of pineapple jam which you give to your aunt Emma (aunt Emma doesn't like pineapple jam) for her to put in the barley hopper. So, this way, nobody will know the password and be able to know, unless they read /.

Re:Uhh

[Phillup]

I think when the parent refers to a 'hash' he means a perl hash, not a cryptographic hash.

Problem is retarded 'complexity' requirements

[Gothmolly]

Where I work, you must have a capital letter, and at least one number. You must change it every 4 weeks, and you cannot reuse any of the last 9. I consider this just on the verge of silly, but it can easily be circumvented like so:

Pick a person's name, say, Annakin.
Add a number or two to the name, Annakin123.
When the password expires, change to Annakin234, then Annakin345...
3) Profit!

Our AD guys are constantly battling the Infosec weenies who claim we need to have even stricter passwd policies, which will result in even MORE Post-It notes underneath keyboards.

If you share an account over which you have no control, get Passkeeper, or develop a "seed" algorithm, that knowing the code, and the seed word, and the hostname, you can derive the password, so you can easily remember it, i.e.

Seed is "slash"
Algorithm = seed + 3rd octet of hostname + first letter of hostname + last letter of hostname.
(or similar, I just thought this up off the top of my head)

Immune to all but dictionary attacks, and you and coworkers can easily derive it on the fly.
Potential security breach? Just change the seed word.