[Owasp-boston] Password Question

Javed Ikbal javed at zsquad.com
Thu Dec 31 15:28:35 EST 2009


LB:
I call it the "Turtle All The Way" problem. No matter where you put it
(in a Java keystore, for example), you will still need a password either
hardcoded in your software, or left in the clear on disk.

Here are some solutions. See which fits your risk tolerance and budget.

First, commercial and expensive:
http://www.cyber-ark.com/identity-access-management-solutions/application-password-management.asp

This works well

There may be others, I am not familiar with any other product.

Hard-coding passwords is generally not a good idea. If you must use that
approach, set the filesystem permissions so that not everyone can read
the script containing the password. (for compiled programs, reading the
password is not trivial, but it makes changing the password very difficult)

NEVER (assuming this is some *nix) supply passwords to a script as a
command-line argument (then a ps -aef might show the password)

My preferred, cheap (read: free) approach is below. Note that this is
NOT cryptographically secure, and will give up the password to someone
who can follow the code (hence the file permission)

I know this isn't foolproof, but better than clear-text pw on disk.

1. Put the password in a file. Encrypt it (some strong cipher) with a
key. Do not store the key anywhere on that machine--remember it or write
it down and put it in a safe. Naturally, back up the password file as well.
(if you have more than one application or script, you can put each
password in the file)

2. Write another program. At each system boot, it will prompt the
sysadmin for the key, decrypt the password file, and store the passwords
in an obfuscated form in shared memory

3. Your scripts (that talk to the db) need to know how to de-obfuscate
the password, and where to look for it in shared memory.

Good: No password in clear-text--you pass the audit
Bad: If the system goes down, it will require human intervention (but
for only one key that will unlock all the passwords)
Bad: People reading the script will know where to look for the
obfuscated PW and how to make it readable.

Happy New Year!

Javed
-------------------------------------------------------------------
Javed Ikbal, CISSP, CISM, CISA
Principal
www.zsquad.com | E: javed at zsquad.com
P: 617 780 9052 | F: 781 723 0590

> 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.
>>
>> Regards,
>> L.B.
>>
>>
>>
>> _______________________________________________
>> Owasp-boston mailing list
>> Owasp-boston at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-boston
>>
>>
>>     
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-boston/attachments/20091231/e717df01/attachment.html 


More information about the Owasp-boston mailing list