What are safe solutions to protecting important credentials in source code

Question

I am doing some Java work for a company that has some code that they want protected in an application that they are giving to their customers.

For example what if you have information such as FTP or DB login information in the client side application source code? The login would be visible to anyone who viewed the code, so access to your server is right out there in the open, which means your code on the server would also be vulnerable. Should the login information be protected by sending information using HTTPConnection/HTTPClient to the server to be processed while using Encryption in transit and sending login credentials to verify request is from a legitimate source.

However wouldn't that also prove to be risky in case the server is hacked/breached, and the Java source would be wide open? (Apparently Execelsior can do server protection with Tomcat applications so there is also that).

---

I was also looking into various Java-to-Exe programs such as Excelsior Jet, but I also ran into programs that simulate Exe's and apparently have protection such as JWrapper.

I had read in this question https://stackoverflow.com/questions/2244321/does-compilng-java-code-to-exe-e-g-using-launch4java-ensure-code-cannot-be-re

That the emulated exe's are not protected, and still contain Jar files, so I'm assuming the best bet are programs similar to Execelsior Jet, and a program such as JWrapper would not be good then?

---

Would it take more time for someone to decompile Native code than to try and hack a server (if they even knew what to look for, or that we are even trying to hide anything). My best bet would be doing server + Excelsior, but the price also goes up if I want to get their Enterprise version instead of Professional.

I am curious what approach people would recommend for safe protection methods. Thank you.

---

EDIT: This question is not a duplicate, because the other question asks about protecting Web Application code from "Web Hosts."

I am asking what the best method of protecting my source code would be. Whether Desktop, or server based. The other question could make sense if I was looking at a server solution, but doesn't provide a solution to my need.

Thank you.

EDIT2: It seems the consensus is that "if someone wants to break, they will..." but isn't there a point to protecting it to stop anyone from just looking at the code? There are coders who aren't knowledgeable in reverse-engineering, but still can understand code if it's readable.

Answer 1

There are 2 obvious problems with credentials being stored in the source code are:

1. The source code can be easily reverse engineered and the credentials extracted.
2. If the credentials are leaked, you would have to change the password on the server, change the password in the code, rebuild and re-deploy

So one option to get round both of these issues is not to have the credentials in the source code at all. A suitably protected configuration file may be all you need, read in the credentials when needed, use them and then clear out the memory after use.

Answer 2

This also brings up the point that what if you have information such as FTP or DB login information in the client side application?

In this case it looks like you want to hide credentials in your Java code which are most likely String constants. If that is the case this question from StackOverflow may be helpful.

Answer 3

What you want (and I said what you want, which is not necessarily what you need as highlighted by other answers and comments) is called code obfuscation.

Code obfuscation is a set of techniques which, given a source code as input, while produce a functionally equivalent but very hard to read / understand source code at the output.

However, be aware of consequences, not only upstream but also down the road since your software will become a lot harder to maintain.

For instance, Java rely a lot on stack traces to diagnose issues, such stack trace usually give clear information about where the error happened. With a correctly obfuscated code, the stack trace will have no meaning anymore:

• Customers will have no mean to resolve even basic issues, thus increasing calls to your support services.
• Your support will have less elements to investigate from the customer (as per my experience at least acting as a client to such company, they seem to have no easy mean to de-obfuscate their own stack trace).

In the realm of corporate software, this is rarely used since the cost usually goes over the benefits (but some indeed use it) and a company really willing to reverse engineer your software will most likely do it anyway.

This may be more frequent in some specific domains, like online playing games (MMORPGs for instance) targeting a substantially wider audience and where the risks associated to reverse engineering may be higher. This however does not count as a reliable protection, just a measure amongst others designed to slow-down attackers and deter casual crackers (with the same disadvantages regarding support issues and poor customer relationship).

Answer 4

Let's think about what code is for a second. Code is a list of instructions for a device (a processor) to do something. Processors are designed by humans, so it's logical that a human would be able to understand code designed for it and be able to replicate its functionality given enough time and effort.

What you're looking for is essentially impossible - maybe it will be with quantum cryptography where merely looking at information will alter it, but in the meantime it's not.

Maybe the solutions you describe will be enough to protect your code. If you're just looking to prevent kids from using your software this will do the trick, but those same kids will probably never have the money to buy your software anyway, so it's not like you're loosing much. On the other hand, imagine if as a kid you were facing two corporations - one openly giving you the code, and one doing their best to prevent you from using it - once an adult with money, if you had to do business with either of them, which one would you choose? Personally I would choose the former, because they still helped me out while I had no money to pay them. You're basically saving money on the short term without thinking long term.

This is similar to piracy. Some people will pour unlimited amount of money into trying to prevent it, but even then it'll eventually get breached, and all that money goes to waste.

I suggest a different approach, instead of trying to prevent theft/piracy which you'll never be able to achieve completely, try to appeal to your paying customers instead. Make it worth it to be a paying customer. Maybe it's hard to believe, but there are people that are willing to pay money for good software. Focus on them - do they have a feature request, or are looking for technical support? Invest your money there.

If you do still want to try and protect your code, there is a way to do it. Put in on a computer hosted at home, and keep an eye on it 24/24. Or even better, don't even write code (what if your development machine is already compromised?) and do whatever your valuable app does but directly in your head. This should be fairly safe, and you don't have to trust a hosting provider nor employees.

Hopefully this explains well enough why you have to trust someone, like an infrastructure provider. Fortunately enough, not everyone is a crook, and most infrastructure companies out there will happily host your application, making good money from what they already do best without betraying your trust and stealing your application.

Answer 5

I would recommend obfuscation, then making the password look like the obfuscated code, then leave a bunch of honeypot passwords.