How to Protect MySQL Username and Password from Decompiling

How can I protect MySQL username and password from decompiling?

Never hard-code passwords into your code. This was brought up recently in the Top 25 Most Dangerous Programming Mistakes:

Hard-coding a secret account and
password into your software is
extremely convenient -- for skilled
reverse engineers. If the password is
the same across all your software,
then every customer becomes vulnerable
when that password inevitably becomes
known. And because it's hard-coded,
it's a huge pain to fix.

You should store configuration information, including passwords, in a separate file that the application reads when it starts. That is the only real way to prevent the password from leaking as a result of decompilation (never compile it into the binary to begin with).

For more information about this common mistake, you can read the CWE-259 article. The article contains a more thorough definition, examples, and lots of other information about the problem.

In Java, one of the easiest ways to do this is to use the Preferences class. It is designed to store all sorts of program settings, some of which could include a username and password.

import java.util.prefs.Preferences;

public class DemoApplication {
  Preferences preferences = 
      Preferences.userNodeForPackage(DemoApplication.class);

  public void setCredentials(String username, String password) {
    preferences.put("db_username", username);
    preferences.put("db_password", password);
  }

  public String getUsername() {
    return preferences.get("db_username", null);
  }

  public String getPassword() {
    return preferences.get("db_password", null);
  }

  // your code here
}

In the above code, you could call the setCredentials method after showing a dialog askign for the username and password. When you need to connect to the database, you can just use the getUsername and getPassword methods to retrieve the stored values. The login credentials will not be hard-coded into your binaries, so decompilation will not pose a security risk.

Important Note: The preference files are just plain text XML files. Make sure you take appropriate steps to prevent unauthorized users from viewing the raw files (UNIX permissions, Windows permissions, et cetera). In Linux, at least, this isn't a problem, because calling Preferences.userNodeForPackage will create the XML file in the current user's home directory, which is non-readable by other users anyway. In Windows, the situation might be different.

More Important Notes: There has been a lot of discussion in the comments of this answer and others about what the correct architecture is for this situation. The original question doesn't really mention the context in which the application is being used, so I will talk about the two situations I can think of. The first is the case in which the person using the program already knows (and is authorized to know) the database credentials. The second is the case in which you, the developer, are trying to keep the database credentials secret from the person using the program.

First Case: User is authorized to know the database login credentials

In this case, the solution I mentioned above will work. The Java Preference class will stored the username and password in plain text, but the preferences file will only be readable by the authorized user. The user can simply open the preferences XML file and read the login credentials, but that is not a security risk because the user knew the credentials to begin with.

Second Case: Trying to hide login credentials from the user

This is the more complicated case: the user should not know the login credentials but still needs access to the database. In this case, the user running the application has direct access to the database, which means the program needs to know the login credentials ahead of time. The solution I mentioned above is not appropriate for this case. You can store the database login credentials in a preferences file, but he user will be able to read that file, since they will be the owner. In fact, there is really no good way to use this case in a secure way.

Correct Case: Using a multi-tier architecture

The correct way to do it is to have a middle layer, in between your database server and your client application, that authenticates individual users and allows a limited set of operations to be performed. Each user would have their own login credentials, but not for the database server. The credentials would allow access to the middle layer (the business logic tier) and would be different for each user.

Every user would have their own username and password, which could be stored locally in a preferences file without any security risk. This is called a three-tier architecture (the tiers being your database server, business logic server, and client application). It is more complex, but it really is the most secure way to do this sort of thing.

The basic order of operations is:

1. Client authenticates with business logic tier using the user's personal username/password. The username and password are known to the user and are not related to the database login credentials in any way.
2. If authentication succeeds, the client makes a request to the business logic tier asking for some information from the database. For example, an inventory of products. Note that the client's request is not a SQL query; it is a remote procedure call such as getInventoryList.
3. The business logic tier connects to the database and retrieves the requested information. The business logic tier is in charge of forming a secure SQL query based on the user's request. Any parameters to the SQL query should be sanitized to prevent SQL injection attacks.
4. The business logic tier sends the inventory list back to the client application.
5. The client displays the inventory list to the user.

Note that in the entire process, the client application never connects directly to the database. The business logic tier receives a request from an authenticated user, processes the client's request for an inventory list, and only then executes a SQL query.

Prevent decompilation of password data

The simpliest way - you can use tools from System.Security.Cryptography namespace to encrypt your credentials and then use any obfuscator to make decription process little harder.

But it's only question of time when someone recovers it.

The right way - to hide your database behind web service with public API. It requires more effort but will reduce security riscs significantly.

Security of Database passwords (and other important private strings ) in a java application

Nothing you release to the public is private. There is no protection scheme that a sufficiently motivated attacker cannot break. If anybody had one, they'd be making millions selling it to Hollywood! (Plenty of people are making millions selling ones that don't work...)

You have three basic options:

1) Design the database with procedures and permissions such that having the direct login doesn't allow the user to do anything they couldn't have done through the application anyway.

2) Tie user accounts to database accounts and have users login with their own username.

3) Put an application server in front of the database. Your client connects to the application server and calls service methods on it. So only those functions you expose on the app server are exposed to the public. This is the standard way of doing things.

Secure Database Connection from decompilation inspection

Don't have the application talking directly to the SQL server. Have it talking to a web-facing API that can talk to the SQL server and your application talking to the API. .Net Web Services / WCF make this really easy .

---

Related Topics