Re: Protecting passwords in Perl scripts?
From: Mark Shelor (mshelor_at_comcast.removeme.net)
Date: 09/18/04
- Next message: Nitin: "Re: problem fetching *only one* value."
- Previous message: Peter Scott: "Re: anonymous hash notation question"
- In reply to: David Filmer: "Protecting passwords in Perl scripts?"
- Next in thread: Scott W Gifford: "Re: Protecting passwords in Perl scripts?"
- Reply: Scott W Gifford: "Re: Protecting passwords in Perl scripts?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 18 Sep 2004 09:23:37 -0700
David Filmer wrote:
> I have (for example) a Perl script that connects to a database (or FTP site,
> etc). The database (or ftp) password is either hard-coded (in clear text) in
> the script or contained in an external configuration file (which must be
> readable by the effective uid of the script).
>
> Someone who was able to browse the code could easily determine the password.
> That's a Bad Thing.
>
> I could trivially obfuscate it (rot13, etc) but that would only thwart the
> truly ignorant. The password could be symmetrically encrypted, but the
> script somehow needs to determine the encryption key (and the idly curious
> could determine this as well by reading the code).
>
> How can I shield the database (ftp, etc) password from prying eyes?
I've written and maintained many such scripts, so this is a topic of
personal interest. I believe I've finally settled on an "optimal"
approach, though individual tastes will certainly vary.
There are several possible techniques. Each has its own advantages and
disadvantages, depending on the threat(s) you envisage. But, under
normal circumstances, I'd simply recommend your second option: moving
the passwords to a configuration file, and reading them into the script
at runtime.
Don't bother with encryption or set-id's, at least not initially. They
make software a pain to use and modify, and are likely not appropriate
to the actual threats you face. By moving the passwords to a
configuration file, you solve 90% of the problem: namely, you can now
copy your scripts anywhere or share them with anyone, and cut-and-paste
from them freely without compromising your security.
However, if other users can browse your directories and read your files
at will, then you have a problem. Simply protect your configuration
files from access by others, and you've eliminated most of the
reasonable threats.
That said, if the threats are more dire, I'd recommend encrypting the
configuration files with GnuPG, and then decrypting/re-encrypting them
within your scripts via the --use-agent option. This necessitates
running gpg-agent as a daemon to automate the passphrase handling. Once
you get things set up, this approach is _very_ secure and fairly easy
to maintain. But it's probably overkill for what you're doing.
Or, you can rig up a quick-and-dirty "password safe" in Perl using a
hash tie'ed to a DB_File. There are many ways to obfuscate the contents
of the safe so that running "strings" on the db file won't reveal the
passwords. Still, unlike GnuPG, it won't foil the determined intruder.
Regards, Mark
- Next message: Nitin: "Re: problem fetching *only one* value."
- Previous message: Peter Scott: "Re: anonymous hash notation question"
- In reply to: David Filmer: "Protecting passwords in Perl scripts?"
- Next in thread: Scott W Gifford: "Re: Protecting passwords in Perl scripts?"
- Reply: Scott W Gifford: "Re: Protecting passwords in Perl scripts?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
