Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Embeded passwords

by TechFly (Scribe)
on Aug 29, 2012 at 12:37 UTC ( #990458=perlquestion: print w/replies, xml ) Need Help??
TechFly has asked for the wisdom of the Perl Monks concerning the following question:

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.

Replies are listed 'Best First'.
Re: Embeded passwords
by jethro (Monsignor) on Aug 29, 2012 at 14:09 UTC

    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.

Re: Embeded passwords
by kennethk (Abbot) on Aug 29, 2012 at 13:57 UTC

    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.

    #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

      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.

Re: Embeded passwords
by flexvault (Monsignor) on Aug 29, 2012 at 17:58 UTC


    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!


    "Well done is better than well said." - Benjamin Franklin

Re: Embeded passwords
by sundialsvc4 (Abbot) on Aug 29, 2012 at 14:24 UTC

    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.

Re: Embeded passwords
by Plankton (Vicar) on Aug 30, 2012 at 01:33 UTC
    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.
Re: Embeded passwords
by influx (Beadle) on Aug 29, 2012 at 13:46 UTC
    I don't fully understand what you're trying to do, but can't you use a config file to store the passwords?
Re: Embeded passwords
by sundialsvc4 (Abbot) on Aug 30, 2012 at 12:59 UTC

    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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://990458]
Approved by andye
Front-paged by Old_Gray_Bear
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (3)
As of 2018-06-25 04:36 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (126 votes). Check out past polls.