obfuscate connection string in java

Question

I've made a little program with Java and the library ojdbc14. I've obfuscated with proguard the jar file but if I unzip the program and I check some classes I see easily the connection string of my database connection. Someone could help to obfuscate these connection string? Thanks and sorry for my English!

If you obfuscate the connection string how do you expect your program to connect to the database? And why do you want to obfuscate the connection string, in the first place? — Raffaele, Aug 07 '14 at 15:06
just put in a properties file and restrict permissions to that file to only userid running the application — user3487063, Aug 07 '14 at 15:10

Joop Eggen · Accepted Answer · 2014-08-07T15:18:15.020

1

Instead of

String secret = "secret";

do

String alpha = "sce"; // odd letters
String beta = "fsu"; // even letters + 1
StringBuilder secret = new StringBuilder();
for (int i = 0; i < alpha.length() + beta.length(); ++i) {
    if (i % 2 == 1) {
        secret.append(alpha.charAt(i / 2);
    } else {
        secret.append((char)(beta.charAt(i / 2) - 1);
    }
}

You get the idea.

edited Aug 07 '14 at 15:18

answered Aug 07 '14 at 15:12

Joop Eggen

107,315
7
83
138

score 0 · Answer 2 · edited May 23 '17 at 11:49

0

One easy solution would be to base64 encode the string literal and unencode it when you need to use it. That way, it wouldn't be visible in plain text.

The Apache Commons library has a utility you can use, and it's built in to Java 8.

edited May 23 '17 at 11:49

Community

1
1

answered Aug 07 '14 at 15:08

Patrick Collins

10,306
5
30
69

And what would be the purpose of such a transformation? – Raffaele Aug 07 '14 at 15:12
@Raffaele So the string literal isn't visible in the binary. That's the OP's problem, right? – Patrick Collins Aug 07 '14 at 15:16
OP reminds me of the evergreen *what is the regex to get the of this document*? – Raffaele Aug 07 '14 at 15:19

William F. Jameson · Answer 3 · 2014-08-07T15:30:26.707

I suggest you encrypt your connection string and keep the secret key outside the JAR. Make your program code contain a byte[] initialized with the encrypted bytes.

If you don't want any secret key external to the JAR, then your only option is "security through obscurity". You can, for example, devise some seemingly complex routine which will produce the encryption key at runtime. For example, seed the random number generator with a fixed seed, then take a few numbers from it.

A poor man's encryption approach is a simple XOR. You can generate the fixed pseudorandom sequence and use that to XOR each byte of your connection string:

byte[] password = "password".getBytes(StandardCharsets.UTF_8);
Random rnd = new Random(204862727);
for (int i = 0; i < password.length; i++)
  password[i] ^= rnd.nextInt();
// at this point password contains bytes which you would hardcode into your JAR
System.out.println("Encrypted: "+new String(password, StandardCharsets.UTF_8));
rnd = new Random(204862727);
for (int i = 0; i < password.length; i++)
  password[i] ^= rnd.nextInt();
System.out.println("Decrypted: "+new String(password, StandardCharsets.UTF_8));

On my system, this prints

Encrypted: �ع�gO�
Decrypted: password

Thanks. But if you put the password in the code. When someone unzip the jar cant check password variable and see the plain text, no?. Thanks and sorry for my english — Luis perez, Aug 07 '14 at 15:24
My point was *not* to include the password with the JAR, but make the legitimate client of the JAR pass the password to a method in your JAR. Otherwise, look into my example of security through obscurity. — William F. Jameson, Aug 07 '14 at 15:28

score 0 · Answer 4 · answered Aug 07 '14 at 15:29

Obfuscation has the sole purpose of not letting others easily steal your code. After the binary has been obfuscated, another programmer will find it more difficult to modify and resell your code, or make your program behave differently than you intended (by the way, Proguard also removes dead code, and probably makes other optimizations I cannot recall just now).

There's no value in hiding constants in source code. You could find billions of fancy ways, but what's the purpose? Once the attacker has the code, it will not inspect thousands of .class files: instead, if all she wants is seeing the connection string, she will just attach a debugger. set a breakpoint (the JDBC stack is not obfuscated) and wait for your program to reconstruct the connection string.

Obfuscation is not encryption. If you don't want to ship the connection string with your app (maybe because it contains a secret), then just require the secret to the user interactively at boot time, or read from some location which is marked "safe".

obfuscate connection string in java

4 Answers4