RE: clear-text passwords in shell/perl scripts

["Ofer Shezaf" <Ofer.Shezaf () breach com>]

Well Jeff, I think that you must combine both methods. 

The limitation of file permissions is the numerous privilege escalation
vulnerabilities out there. 

You are right about encrypting passwords with keys stored on the machine
(or otherwise trying to hide the password), but it does help to deter
casual hackers. 

I like Jeremiah Grossman's article "The 80/20 Rule for Web Application
Security" (http://www.webappsec.org/articles/013105-plain.html). We must
always remember the total security is an unachievable goal and that we
should do our best. The chances that a hacker, looking for the weakest
point, will skip us are greater the more we invest in security.

~ Ofer


Ofer Shezaf
CTO, Breach Security

Tel: +972.9.956.0036 ext.212
Cell: +972.54.443.1119
ofers () breach com
http://www.breach.com 


> -----Original Message-----
> From: Jeff Robertson [mailto:Jeff.Robertson () DigitalInsight com]
> Sent: Friday, March 18, 2005 8:19 PM
> To: Webappsec (E-mail)
> Subject: clear-text passwords in shell/perl scripts
>
> Say that a perl script needs access to a database, and access to this
> database requires a password. The script needs to run automatically
with
> no
> human intervention, so it is not possible to prompt a user to enter
the
> password at run time. This means that the password must either be in
the
> script itself or in a file readable by the script.
>
> I have been asked what can be done to protect this password from
falling
> into the wrong eyes. My recommendation is to tightly control read
> permissions to the script and/or the file that contains the password.
Make
> the file owned by a special-purpose user who only exists to run this
> script,
> and chmod it to 600. That sort of thing.
>
> It has been suggested to encrypt the password. Since the script needs
to
> get
> the clear text of the passwords in order to use them, this will need
to be
> symmetric encryption and the script will need to have the key
available,
> presumably stored in yet another file. As there would be no way to
keep
> the
> key from being stolen other than to use the file permissions that were
> being
> relied on previously, you've just increased the complexity of the
system
> without actually making it any more secure. This is bad. You'd be
better
> off
> sticking with the simpler solution, since the security is the same
either
> way.
>
> Can anyone either refute or provide further points in support of my
stance
> on this?
>
> Jeff Robertson
> Manager of Web Application Security
> Digital Insight