Putting passwords in a properties file?

[Uli Kunkel]

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..

Are there any applications with this purpose?
I'd like to know what are practices of other people?


Thanks in advance for any suggestions.

 

[grz01]

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..

Are there any applications with this purpose?
I'd like to know what are practices of other people?

Thanks in advance for any suggestions.

I think this is what you're looking for:

http://www.jasypt.org/

Have only used it briefly (for just such purpose) but worked without
problems.

/ grz01

 

[Uli Kunkel]

I think this is what you're looking for:

http://www.jasypt.org/

Have only used it briefly (for just such purpose) but worked without
problems.

/ grz01

Yes that was exactly what I was looking for.

But I see the problem is in hard-coding the password.
Are there any tricks and suggestions for storing the encryption key?

 

[Xavier Nayrac]

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) ?

 

[Mayeul]

Uli Kunkel a écrit :

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

Errrm, assuming it would be possible to do, which I doubt, you'd still
just need the hash to gain access.

Doesn't seem to change much, does it?

 

[Uli Kunkel]

Who are you trying to protect the password from? There are many
methods suitable for different situations.

One possible method is to store the password as two byte arrays.
Convert the password to an array of bytes. Then generate a second
byte array the same length filled with random bytes using SecureRandom
(not Random). Store the random byte array and the XOR of the two
arrays. If you are using a text only storage medium, such as the
properties file, then you may need to convert to Base64 text before
storing. Consider putting one array in the properties file and the
other array elsewhere.

To recover the password read the two byte arrays. XOR the two
together and convert the resulting byte array back into the origial
text password.

Encryption:
cyphertext <- plaintext XOR key

Decryption:
plaintext <- cyphertext XOR key

Change the second, random, byte array regularly. How regularly
depends on how secure you want things to be. It is probably easy
enough to change it every time the password is used which gives you a
One Time Pad.

Do not call the two stored byte arrays "password1" and "password2"!

For something more secure, keep the decryption key (the random array)
on a USB stick that is removed from the computer and stored in a
locked safe when the password in not needed.

rossum

The principle of what you are saying is the same as Jasypt jar...
The problem is in that second byte array because I need to hold it in
the application.
It's a server application so I cannot use a usb stick for holding it.

 

[grz01]

The principle of what you are saying is the same as Jasypt jar...
The problem is in that second byte array because I need to hold it in
the application.
It's a server application so I cannot use a usb stick for holding it.

Well, ultimately, the application needs to be able to read something
(like the decryption-key) from a storage protected from unauthorized
access.

The simplest(?) way is to put that sensitive information in a disk-
file,
with file-access protection that allows only the owner of the file (or
the superuser) to read it.
And the owner should be the OS-identity under which the application
runs.

In unix/linux, it's something like file-permission:
-r--------

Windows, of course, has some similar (but more complex) corresponding
mechanism,
but I'm not too familiar with that one.

 

[Lew]

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.

 

[Nigel Wade]

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.

 

[grz01]

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.

No, its not quite what un*x does anymore -- piece-of-cake today to
brute-force the passwd file if you use public pw-hashes.

The pw-hashes must be stored in a protected place (unless you're fine
with "toy security").

See:

http://en.wikipedia.org/wiki/Shadow_password

 

[jolz]

But I see the problem is in hard-coding the password.

Are there any tricks and suggestions for storing the encryption key?

I use Zelix KlassMaster with string encryption enabled that makes a
little harder to find the key. But since the key is there to decode the
password I do have class that does this, so the key isn't necessary to
decode the password - finding the right class (obviously obfuscated) may
be easier.

 

[alexandre_paterson]

The pw-hashes must be stored in a protected place (unless you're fine
with "toy security").

Wait... (my post is apparently unrelated to the OP's problem btw)

I agree that storing {hash} is stupid, but long before
shadow passwords Un*x systems where already storing:

{hash(password+salt),salt}.

(a long time ago it was a lame 12-bit salt, but nothing stops me
nor anyone from using a much bigger salt, which I sure did

Are you saying that storing {hash(password+64-bit salt), 64-bit salt}
without the equivalent of shadow passwords would be "toy security"?

 

[alexandre_paterson]

On Sep 25, 6:11 pm, "Mike Schilling" <[email protected]>
wrote:
....

As illustrated in Cliff Stoll's wonderful _The Cuckoo's Egg_.

What the 20-years old book shows is a dictionary attack on a passwd
file that is using no salt.

Modern Un*x distro ('modern' as in "since at least 20 years") are
storing {hash(password+salt),salt} instead of {hash} as I explained
in the other post.

The attack used in the book only works on the most
naive form of password hash storage.

What about you guys all bring your dictionary
attacks/rainbow tables/ terabytes of memory/tables
supercomputers and I publish here in the clear
a cryptographic hash of a password using a 32-bit
salt (and the 32-bit salt used of course)?

Then we'll see if it's "piece-of-cake" and "toy security"
and if 20 years old romance is adapted to modern form
of password hash storage

 

[Dave Searles]

Wait... (my post is apparently unrelated to the OP's problem btw)

I agree that storing {hash} is stupid, but long before
shadow passwords Un*x systems where already storing:

{hash(password+salt),salt}.

(a long time ago it was a lame 12-bit salt, but nothing stops me
nor anyone from using a much bigger salt, which I sure did

Are you saying that storing {hash(password+64-bit salt), 64-bit salt}
without the equivalent of shadow passwords would be "toy security"?

It seems to me that if you have the hash and the salt, and know the
algorithm for convolving the password with the salt, then you can still
carry out a dictionary attack.

On the other hand, if the password is something like zs1df3rh, good luck
with that.

 

[Tom Anderson]

It seems to me that if you have the hash and the salt, and know the algorithm
for convolving the password with the salt, then you can still carry out a
dictionary attack.

On the other hand, if the password is something like zs1df3rh, good luck with
that.

The point is that without a salt, you can make one pass through the
dictionary and recover *all* the passwords in the file:

for word in dictionary:
hashedWord = hash(word)
for username, hashedPassword in passwordFile:
if (hashedPassword == hashedWord):
print username, hashedWord # pwned!

Whereas with a salt, you need to do a different computation for each user:

for word in dictionary:
for username, salt, hashedPassword in passwordFile:
hashedWord = hash(word, salt)
if (hashedPassword == hashedWord):
print username, hashedWord # pwned!

Note that in the former case, the hashing operation is inside the word
loop; in the latter, it is inside the loop over the passwords. If you have
w words and u users, then the former is O(w) to crack all users, whereas
the latter is O(w*u) to crack them all. Correspondingly, the time taken to
crack any one user is something very vaguely like O(w/u) in the former
case, and O(w) in the latter.

Which means that Alexandre's challenge is actually rather silly. Adding
salt doesn't make any single password more secure, it makes the population
of passwords more secure. If he's giving us a single password to work on,
then the salt will make no difference.

tom

 

[markspace]

It seems to me that if you have the hash and the salt, and know the
algorithm for convolving the password with the salt, then you can still
carry out a dictionary attack.

A dictionary attack pre-computes the hash, and then just scans the
password file for a simple string match. The salt defeats this, because
each bit in the salt doubles the storage needed for the dictionary.

<http://en.wikipedia.org/wiki/Salt_(cryptography)>

You're right in that if the password itself is weak and could be
guessed, then all bets are off.

 

[Roedy Green]

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.

If your program can decrypt the passwords to plaintext, so can any
hacker. Further he can snoop on your socket when the apps sends the
passwords off to some other site. Anything you do to hide the
passwords is just disguising them from casual observation.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Civilisation advances by extending the number of important operations which we can perform without thinking about them."
~ Alfred North Whitehead (born: 1861-02-15 died: 1947-12-30 at age: 86)

 

[Dave Searles]

A dictionary attack pre-computes the hash, and then just scans the
password file for a simple string match. The salt defeats this, because
each bit in the salt doubles the storage needed for the dictionary.

<http://en.wikipedia.org/wiki/Salt_(cryptography)>

You're right in that if the password itself is weak and could be
guessed, then all bets are off.

As Tom explained, the salt does not make any single password harder to
crack, but it does slow down an attack aimed at getting all (or the
first) dictionary-vulnerable password.

I was thinking in terms of protecting a particular targeted account
(yours, say, or the superuser account), while you two were apparently
thinking more of protecting all of the accounts in some statistical sense.

I still think the surest bet is to avoid using dictionary-attackable
passwords.

 

[Mike Schilling]

I still think the surest bet is to avoid using dictionary-attackable
passwords.

Absolutely, which is why many environments require passwords to contain both
letters and numbers.

 

[Tom Anderson]

Absolutely, which is why many environments require passwords to contain
both letters and numbers.

Which is absolutely not a good defence. "pa55w0rd" and "password1", which
are the kind of thing this rule usually engenders, are not a lot more
difficult to guess than "password" - it's a small constant-factor increase
in the amount of work a password cracker has to do.

What would really make a difference is expanding password boxes to 200
characters (FSVO '200'), and telling people to use whole phrases. "I used
to use weensy passwords but now use humongous ones" is going to take a
very long time to guess.

tom