Re: Putting passwords in a properties file?

From:

Nigel Wade <nmw@ion.le.ac.uk>

Newsgroups:

comp.lang.java.programmer

Date:

Fri, 25 Sep 2009 13:29:01 +0000 (UTC)

Message-ID:

<h9igit$mgi$1@south.jnrs.ja.net>

On Fri, 25 Sep 2009 08:22:21 -0400, Lew wrote:

rossum wrote:

On Fri, 25 Sep 2009 11:43:13 +0200, Xavier Nayrac
<xavier____n_a_yrac@gmail.com> wrote:

Uli Kunkel a ??crit :

I need to put a password for something as an application parameter.
For now I'm using a properties file but the password isn't encrypted.

I suppose I could encrypt with something and hardcode that encryption
key in the application..

Why use a key ? Why not use an hash (SHA*, md5) ?

As I understand the question, this is not a file of user passwords that
are checked when the users log on; for that purpose using a hash would
be correct. This appears to be a password to a back end application
(?database?) that the server is logging on to, and the server needs to
pass the actual password to the application, not a hash of the
password.

For this purpose the ability to decrypt to get back the original text
of the password is essential. Hence the need for a key.

What I've tried, but I cannot vouch for the non-hackability of it, is to
store the hash (e.g., MD5) of the password in the file or database.
When a user logs on, I compare the hash of their password to the stored
value.

I imagine that a hacker who obtained the stored value would have trouble
reversing the hash to a valid password.

This makes the ability to decrypt to get back the original text of the
password non-essential.

I would think it's pretty robust. It's what UNIX does (and maybe has
always done). UNIX doesn't store passwords in the passwd database (or
whatever other database it uses e.g. LDAP). It uses the crypt hashing
function and stores the hash. Any time it needs to authenticate a
password against the hash it crypts the password using the same algorithm
and compares that to the stored hash.

--
Nigel Wade