Putting passwords in a properties file?
in [Java Help]
|
Prev: Some projects were hidden because they exist in the workspace directory
Next: light weight types
From: Lew on 25 Sep 2009 08:22 rossum wrote: > On Fri, 25 Sep 2009 11:43:13 +0200, Xavier Nayrac > <xavier____n_a_yrac(a)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. -- Lew
From: Nigel Wade on 25 Sep 2009 09:29 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(a)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
From: grz01 on 25 Sep 2009 12:11 On Sep 25, 3:29 pm, Nigel Wade <n...(a)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
From: jolz on 25 Sep 2009 12:22 > 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.
From: Leif Roar Moldskred on 25 Sep 2009 12:31
Uli Kunkel <genijalac(a)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? When I've had to do this, I've worked from the assumption that if an attacker has access to the property file with the password he's already on the system the program is running on and has access to everything the program has access to, including the byte code. Under that assumption, the determined attacker will always have (potential) access to the ciphertext, the key and the decryption algorithm. That means there is no way to make the password cryptographically secure -- but we can obfuscate it to make it _harder_ for the attacker. I just put the key in the same property file as the encrypted password, scrambled with a simple, hard-coded transform to prevent it from being immediately useable (but nothing that would stand up to a cryptographic attack.) If it makes sense for the deployment (i.e. "Will this be maintainable by the line-organisation?"), I'll put a secondary encryption key into an enviornment variable with an unassuming name and use that to encrypt all the primary encryption keys. This way, an attacker will need three separate pieces: the property file, the program code (either the source code or the byte code) and the contents of the environment variable. It's _not_ 100% secure, but it will stump all incidental attackers and some determined ones. (On another note, don't put the passwords in the regular configuration file, but put them in a separate configuration file with nothing but passwords. The regular configuration files tend to be bandied about with abandon when someone is having a problem and can end up in all sorts of places.) -- Leif Roar Moldskred |