Putting passwords in a properties file?

Discussion in 'Java' started by Uli Kunkel, Sep 25, 2009.

  1. Uli Kunkel

    Uli Kunkel Guest

    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.
     
    Uli Kunkel, Sep 25, 2009
    #1
    1. Advertising

  2. Uli Kunkel

    grz01 Guest

    On Sep 25, 9:37 am, 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.


    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, Sep 25, 2009
    #2
    1. Advertising

  3. Uli Kunkel

    Uli Kunkel Guest

    grz01 wrote:
    > On Sep 25, 9:37 am, 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.

    >
    > 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, Sep 25, 2009
    #3
  4. 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, Sep 25, 2009
    #4
  5. Uli Kunkel

    Mayeul Guest

    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
     
    Mayeul, Sep 25, 2009
    #5
  6. Uli Kunkel

    Uli Kunkel Guest

    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.
     
    Uli Kunkel, Sep 25, 2009
    #6
  7. Uli Kunkel

    grz01 Guest

    On Sep 25, 1:11 pm, Uli Kunkel <> wrote:
    > 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.


    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.
     
    grz01, Sep 25, 2009
    #7
  8. Uli Kunkel

    Lew Guest

    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
     
    Lew, Sep 25, 2009
    #8
  9. Uli Kunkel

    Nigel Wade Guest

    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
     
    Nigel Wade, Sep 25, 2009
    #9
  10. Uli Kunkel

    grz01 Guest

    On Sep 25, 3:29 pm, Nigel Wade <> 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
     
    grz01, Sep 25, 2009
    #10
  11. Uli Kunkel

    jolz Guest

    > 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.
     
    jolz, Sep 25, 2009
    #11
  12. Uli Kunkel

    Guest

    On Sep 25, 5:11 pm, grz01 <> wrote:
    ....
    > 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"?
     
    , Sep 27, 2009
    #12
  13. Uli Kunkel

    Guest

    On Sep 25, 6:11 pm, "Mike Schilling" <>
    wrote:
    ....
    > > 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.

    >
    > 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 :)
     
    , Sep 27, 2009
    #13
  14. Uli Kunkel

    Dave Searles Guest

    wrote:
    > On Sep 25, 5:11 pm, grz01 <> wrote:
    > ...
    >> 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"?


    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.
     
    Dave Searles, Sep 27, 2009
    #14
  15. Uli Kunkel

    Tom Anderson Guest

    On Sun, 27 Sep 2009, Dave Searles wrote:

    > wrote:
    >> On Sep 25, 5:11 pm, grz01 <> wrote:
    >> ...
    >>> 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"?

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

    --
    There is no latest trend.
     
    Tom Anderson, Sep 27, 2009
    #15
  16. Uli Kunkel

    markspace Guest

    Dave Searles wrote:
    >
    > 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_%28cryptography%29>

    You're right in that if the password itself is weak and could be
    guessed, then all bets are off.
     
    markspace, Sep 27, 2009
    #16
  17. Uli Kunkel

    Roedy Green Guest

    On Fri, 25 Sep 2009 09:37:13 +0200, Uli Kunkel <>
    wrote, quoted or indirectly quoted someone who said :

    >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)
     
    Roedy Green, Sep 27, 2009
    #17
  18. Uli Kunkel

    Dave Searles Guest

    markspace wrote:
    > Dave Searles wrote:
    >>
    >> 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_%28cryptography%29>
    >
    > 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. :)
     
    Dave Searles, Sep 28, 2009
    #18
  19. Dave Searles wrote:
    >
    > 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.
     
    Mike Schilling, Sep 28, 2009
    #19
  20. Uli Kunkel

    Tom Anderson Guest

    On Mon, 28 Sep 2009, Mike Schilling wrote:

    > Dave Searles wrote:
    >
    >> 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.


    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

    --
    I am the best at what i do.
     
    Tom Anderson, Sep 28, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John
    Replies:
    6
    Views:
    683
  2. Bishoy George

    putting struct properties into dropdownlist

    Bishoy George, Oct 6, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    426
    Bishoy George
    Oct 6, 2005
  3. Ahmed Moustafa
    Replies:
    5
    Views:
    463
    Brian Palmer
    Aug 20, 2003
  4. Saurabh
    Replies:
    6
    Views:
    4,618
    Chris Smith
    May 30, 2004
  5. Replies:
    8
    Views:
    446
Loading...

Share This Page