http://www.perlmonks.org?node_id=1185953

nysus has asked for the wisdom of the Perl Monks concerning the following question:

I have a script that needs passwords for things like mysql databases on other servers. I want to do this as painlessly and as securely as possible. So what I'm thinking is that my script would prompt for a single master password and then it would be granted access to the other passwords. I found this possible solution which explains how to use the KeePass module which seems like it might be a good route. But I wanted to get some input from the Monks who might have other good ideas. Many thanks.

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate";
$nysus = $PM . ' ' . $MCF;
Click here if you love Perl Monks

Replies are listed 'Best First'.
Re: Accessing passwords in a script
by marto (Cardinal) on Mar 25, 2017 at 20:36 UTC

    this along with the other responses to it's parent should be of interest to you.

Re: Accessing passwords in a script
by davido (Cardinal) on Mar 25, 2017 at 21:07 UTC

    Vault, by Hashicorp is a great solution nowadays. There's still a bit of a chicken/egg issue though. Eventually an application needs a way to store password it can use to authenticate, either with the individual services it connects to, or with a single service such as Vault which then provides credentials to use with the other individual services.

    One fairly common practice is to have a non-committed config file that has to be manually installed on the box that runs your code. It's not committed to any repository. If someone pwns the box they'll get the password/token/etc. But you would have bigger problems by then anyway. The biggest problem with this practice is that someone always forgets and commits the special config file, and then everything in it needs to be rotated again.


    Dave

Re: Accessing passwords in a script
by cbeckley (Curate) on Mar 26, 2017 at 14:17 UTC

    The most important consideration may be, what do the auditors accept?

    Auditors do not like text files. Period.

    Auditors are mostly ok with public/private key pairs.
    They don't seem to mind Oracle's wallet.
    Key stores seem to be a mixed bag.

    As an Oracle DBA, and familiar with the wallet, it makes no sense to me that Oracle wallet is ok, but a read only text file is not. A hacker needs to crack Oracle to get access to the config file, and once they're Oracle, the wallet is theirs to toy with. As is the database ... as are the private keys ... that text file is the least of your problems ...

    Whatever you do, don't let the auditors, or the people in your organization who's only job is to handle the auditors, know that you're pondering security considerations, lest every decision you make for the next four years gets forwarded to committee for review. You'll have to quit your job in order to even think about doing another honest day's work ever again. Ever. Like Ever. </rant> Oops, I forgot my opening rant tag. (And apologies to Taylor Swift)

    Thanks,
    cbeckley

Re: Accessing passwords in a script
by FreeBeerReekingMonk (Deacon) on Mar 26, 2017 at 15:33 UTC
    roll with it. however, I see another danger: At some point, admins will get lazy and not want to log in and restart the thing again and again, so they hardcode the password somewhere.

    rule 1: make sure it is stable and does not need much restarting.

    In most cases, you log the error, then die. And a process-monitor/helpdesk should pick up it's absence.
    In some cases, the daemon needs to be up just to tell other applications it is down. (like a webserver without database backend)

    Some ideas for the latter case:

    Daemon detects it starts password-less, and without a TTY to ask for $pwd=<STDIN>
    It does $0 = $0 . ' - NOPASSWORD' so you can see with ps -ef the state it is in.

    You run a local small sendpwd perlscript that:

    0. Does not show the password with ps -ef
    1. sends the daemon a SIGUSR1, the daemon then creates a named pipe. for example: /tmp/fifo
    2. Once the daemon gets a valid password it closes and deletes the pipe.
    3. The daemon updates its process name by removing the "- NOPASSWORD" it had with $0 =~ s/ - NOPASSWORD$//;

    The obvious solution was a special https web-page where you can input your password, but that was deemed undesirable by audit. figures.
    nb: because nobody logged into the machine, there was no audit trace of an action. (yes, all history files were copied to a security server)