Protect built-in password

Question

I have a properties file in java in which I store all the information about my application, for example, the logo image file name, database name, database user password and database password.
I can store the password encrypted in the properties file.
But the key or passphrase can be read from the can using a decompiler.
Is there a way to store a db pass in a properties file safely?

Answer 1

There are several ways to manage this. If you can determine how to provide the user with a password for the keystore when the application starts, the most appropriate way would be to encrypt all the values ​​with the key and store that key in the keystore. The command line interface to the keystore is used with keytool. However, JSE does have an API for programmatically accessing the keystore.

If you can’t manually provide the password for the keystore at startup (say, for a web application), one way to do this is to write an extremely complicated obfuscation procedure that can confuse the key and save it in the properties file. It is important to remember that the obfuscation and deobfuscation logic must be multi-layered (it may include scrambling, coding, introducing false characters, etc.) and it must have at least one key that can be hidden in other classes of the application using non-intuitive names. This is not a completely safe mechanism, since someone with a decompiler and enough time and intelligence can still work around it, but this is the only one I know about that does not require you to break into your own (i.e. not easily decompiled ) the code.

Answer 2

The SHA1 hash of the password is stored in the properties file. Then, when you verify the user password, you try to log in and make sure that both hashes match.

This is the code that will contain some bytes for you. You can easily pass bytes from a string using the getBytes() method.

 /** * Returns the hash value of the given chars * * Uses the default hash algorithm described above * * @param in * the byte[] to hash * @return a byte[] of hashed values */ public static byte[] getHashedBytes(byte[] in) { MessageDigest msg; try { msg = MessageDigest.getInstance(hashingAlgorithmUsed); } catch (NoSuchAlgorithmException e) { throw new AssertionError("Someone chose to use a hashing algorithm that doesn't exist. Epic fail, go change it in the Util file. SHA(1) or MD5"); } msg.update(in); return msg.digest(); } 

Answer 3

No no. Even if you encrypt it, someone decompiles the code that decrypts it.

Answer 4

You can create a separate properties file (outside the bank) for passwords (either a direct DB password or a key passphrase) and not include this properties file in the distribution kit. Or you can force the server to accept this login only from a specific machine, so that a substitution is required.

Answer 5

In addition to encrypting passwords, as described above, put any passwords in a separate properties file and, when deploying, try to give this file the maximum permissions.

For example, if your Application Server runs on Linux / Unix as root , then create a password property file owned by root with permissions of 400 / -r-------- .

Answer 6

Could you connect to the server via https and download the password, after authentication in some way, of course?