[Owasp-boston] Password Question
klomeli at gmail.com
Thu Dec 31 13:36:09 EST 2009
I once ran into the same dilemma. Depending on where you work and what
your organizations security sensitivity is, some or all of my
suggestions may not be secure enough. For my particular setting, I
find that these suggestions provide a reasonable level of assurance
the password won't fall into the wrong hands (ie, disgruntled system
admin or an intruder). Here are some options you can consider:
1) Create a long running system process (or daemon) that is
responsible for orchestrating/invoking these jobs. This system daemon
would be responsible for invoking the db-specific jobs with the
appropriate db credentials at runtime. The system daemon itself would
never store the password anywhere but instead would be one of the
pieces of information it would require to be manually specified at
startup. You will want to make sure that attackers can't spawn their
own jobs by ensuring that the job scheduling information is read
directly from the database (which would require the attacker to have
the db credentials to begin with if she wanted to add an 'echo
password' job to the scheduled job list). Or,
2) Have the program that requires the db credentials at startup read
the credentials from a configuration text file and replace the
plain-text configuration file's contents with the encrypted form (in
the event that the file contents are not already encrypted). The
program would have the encryption key obfuscated within the code. Last
time I checked, this was the approach BEA's WebLogic server used. Is
this still the case, anyone?
Each approach has its drawbacks. I feel the first option to be the
safest, but requires the most up-front work and a re-alignment of
administrative practices. The second approach is simpler but less
secure as it is possible an attacker could peer into the programs
contents and possibly determine the configuration file encryption key.
I'd be interested in seeing what other approaches other people suggest.
On Thu, Dec 31, 2009 at 12:15 PM, Sales <Sales at blackjackconsulting.com> wrote:
> Hi Everyone,
> I am not sure if this is the most appropriate place to post app-security
> questions, but here we go >
> I am a security analyst who provides security advisory support to software
> engineering teams at my company. I am not a programmer. I started my
> security journey from the infrastructure side and have grown into a more
> well rounded role.
> When designing application architectures a common problem that I run into is
> secure password management for scripts and jobs. Example: An automated job
> or script needs to authenticate to a database. In this scenario my developer
> might want to store the database password in a clear text configuration file
> or hard code it into the script. I do not like this as a security guy, but I
> do not know of as better solution.
> At some point a password is needed for these jobs to execute. What should I
> be advising my developers to do? Can a java key store be used? Should we be
> hard coding an encrypted password string? Use a certificate?
> I am really stuck on this topic and feel that there must be a standard
> method to solve this problem.
> I would love to hear your collective thoughts.
> Owasp-boston mailing list
> Owasp-boston at lists.owasp.org
More information about the Owasp-boston