«

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.

On Sep 25, 9:37*am, Uli Kunkel <genija...@yahoo.com> wrote:
> 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

grz01 wrote:
> On Sep 25, 9:37 am, Uli Kunkel <genija...@yahoo.com> wrote:
>> 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
>

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?

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

--
Xavier Nayrac

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

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?

--
Mayeul

rossum wrote:
> On Fri, 25 Sep 2009 09:37:13 +0200, Uli Kunkel <>
> wrote:
>
>> 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.
> 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.

On Sep 25, 1:11*pm, Uli Kunkel <genija...@yahoo.com> wrote:
> rossum wrote:
> > On Fri, 25 Sep 2009 09:37:13 +0200, Uli Kunkel <genija...@yahoo.com>
> > wrote:
>
> >> 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.
> > 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.

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.

rossum wrote:
> On Fri, 25 Sep 2009 11:43:13 +0200, Xavier Nayrac
> <> 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.

--
Lew

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

> rossum wrote:
>> On Fri, 25 Sep 2009 11:43:13 +0200, Xavier Nayrac
>> <> 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

On Sep 25, 3:29*pm, Nigel Wade <n...@ion.le.ac.uk> wrote:
> 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


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