Embeded passwords

[TechFly]

I have a bit of a 'where do I begin' question. I need to embed a password, or some kind of authentication to a number of external systems (not just ssh keys unfortunately), but things like MySQL, and some security appliances. We need to have the passwords sent to these devices, but we need to not embed the password clear text in the script.

My first thought was to just create an encryption key, and use the key to decrypt a password file. That leaves the keys, and the file in the same place (system). It seems to me that there should be a better way to do this, but I am having trouble finding anything on how to do this securely. I see lots of people that say to 'hide' the password in a file, or bury it deeply in the code, as if that would make a difference to someone that could read it.

Any advice on how to properly, and securely do this?

As always, thanks for you help guys.

UPDATE: Sorry, I didn't say, but the scripts are CGI code on a website. It complicates most answers I can think of.

[jethro]

There is no easy answer to this one. If you store the password where the script can find it, anyone with the same rights as the script can do the same.

If you have a more secure environment nearby (i.e. root account while script runs as user), you might put the secure part into the root account and leave the user script without knowledge of the password. I.e. a root suid script does the authentication. It also logs the call and alerts everyone if it gets called too often, from the wrong script, at the wrong times.

[kennethk]

If your script can read the password, anyone who can run your script can read the password. If you stick a key in your script, anyone who can read your script can read the key. The script has to be able to locate the file, so anyone who can read the script can read the file's path, so hiding it just makes it harder for you to remember where you stuck it.

Assuming a Linux context, the best way IMHO would be to configure sudo to allow root privalege w/o a password on that script, and then make the password file root-only rw (600, let's say). This will save you by leveraging the security model already in place. If someone has rooted your machine, then nothing on there is secret anymore. See Stack Overflow.

[TechFly]

I should have mentioned that this is a web server (CGI code) that we are trying to keep secure. Running as root is not an option.

[flexvault]

TechFly,

I did something like this for a web-site that uses 'http' and not 'https'. The site required the user to login before seeing his information. The purpose was to prevent malicious updating of user information by hackers, and the site did not hold any sensitive information. The solution was to develop a mathematical Perl algorithm on the server side, and a javascript generated mathematical response from the PC.

The 'cgi-bin' Perl script would send a 'login' screen with dynamically generated tokens that when the person typed the password, javascript would change the tokens to a new set that was sent to the server. Perl on the server would process the new tokens and use the server side 'password' and if they matched correctly, then the user was logged in. The tokens never repeated, and were generated so that they had to be used within 1 minute. If this is what you need, I'll find the code and post it.

For our purposes this was safe enough!

Regards...Ed

[sundialsvc4]

I suggest that you look closely at the authentication methods that are available to these external servers.   For example, many database systems allow for authentication by means of LDAP (OpenDirectory), or more generally through pluggable authentication modules.   In short, you want the target server to recognize the authenticity of the requestor, not only by means of some magic-word or cookie that has been correctly supplied, but by who he is, or perhaps where.   If you embed a password into an application such that anyone anywhere who has access to the server can present that password and be allowed inside the gate, then the entire security of the system devolves to the protection that may be afforded to that magic cookie ... which protection must be presumed to be zero.

[Plankton]

Why not write a Perl script that has as its soul purpose is to supply your CGI scripts the password(s) they need. You would need to invoke this script from the command-line so it can prompt you for the password. This script then forks off into the background (becomes a daemon) and listens for connections and responds with the password. That way the password only exist in your brain and the daemon process. Of course someone could still modify your CGI scripts to print out the password it received from the daemon, but it is more secure that hardcoding the password in your CGI's. Also there are plenty of nodes that discuss similar problems, like Hiding passwords in scripts.

[sundialsvc4]

Re: Update ...   No, it does not complicate anything that “the scripts are CGI code on a website.”   That is assumed.   The CGI servers are the ones who are recognized by the web server as being “authenticated” and then “authorized” to do certain (specific!) things, and, provided that only they are permitted to use the credential, all is well.   Furthermore, the scripts must be stored in such a way that the source-code form cannot be obtained in any way ... or by any other user of those same computer systems.   (Many shared-hosted sites are simply compromised by neighbors, as all of them are in the ftpusers group.)

You should also use firewalls to prevent access to the database servers et al from “outside.”

Use every means possible to ensure that the authentication tokens, even if obtained by a thief, cannot be employed by that thief.

Also note that there is nothing particularly Perl-specific about this discussion ... any other-language site on web site hardening would be equally apropos, and should be reviewed.

[influx]

I don't fully understand what you're trying to do, but can't you use a config file to store the passwords?