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
