¿Cómo puedo proteger el nombre de usuario y la contraseña de MySQL de descompilarse?

Nunca codifique contraseñas en su código. Esto se mencionó recientemente en el Top 25 Errores de programación más peligrosos :

Codificar una cuenta secreta y contraseña en su software es extremadamente conveniente -- para expertos ingeniería inversa. Si la contraseña es lo mismo en todo tu software, entonces cada cliente se vuelve vulnerable cuando esa contraseña se convierte inevitablemente conocido. Y porque está codificado, es un gran dolor fijar.

Debe almacenar la información de configuración, incluidas las contraseñas, en un archivo separado que la aplicación lee cuando se inicia. Esa es la única manera real de evitar que la contraseña se filtre como resultado de la descompilación (nunca compilar en el binario para empezar).

Para obtener más información sobre este error común, puede leer el artículo CWE-259. El artículo contiene una definición más completa, ejemplos y mucha otra información sobre el problema.

En Java, una de las formas más fáciles de hacer esto es usar la clase Preferences. Está diseñado para almacenar todo tipo de configuraciones del programa, algunas de las cuales podrían incluir un nombre de usuario y una contraseña.

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
}

En el código anterior, puede llamar al método setCredentials después de mostrar un diálogo askign para el nombre de usuario y la contraseña. Cuando necesite conectarse a la base de datos, puede usar los métodos getUsername y getPassword para recuperar los valores almacenados. Las credenciales de inicio de sesión no serán codificado en sus binarios, por lo que la descompilación no representará un riesgo de seguridad.

Nota importante: Los archivos de preferencias son solo archivos XML de texto plano. Asegúrese de tomar las medidas adecuadas para evitar que usuarios no autorizados vean los archivos raw (permisos UNIX, permisos de Windows, etc.). En Linux, al menos, esto no es un problema, porque llamar a Preferences.userNodeForPackage creará el archivo XML en el directorio personal del usuario actual, que de todos modos no es legible por otros usuarios. En Windows, la situación podría ser diferente.

Notas más importantes: Ha habido mucha discusión en los comentarios de esta respuesta y otros sobre cuál es la arquitectura correcta para esta situación. La pregunta original realmente no menciona el contexto en el que se está utilizando la aplicación, por lo que hablaré sobre las dos situaciones que se me ocurren. El primero es el caso en el que la persona que utiliza el programa ya conoce (y está autorizada a conocer) la base de datos credencial. El segundo es el caso en el que usted, el desarrollador, está tratando de mantener las credenciales de la base de datos en secreto de la persona que utiliza el programa.

Primer caso: El usuario está autorizado a conocer las credenciales de inicio de sesión de la base de datos

En este caso, la solución que mencioné anteriormente funcionará. La clase Java Preference almacenará el nombre de usuario y la contraseña en texto plano, pero el archivo de preferencias solo será legible por el usuario autorizado. El usuario puede simplemente abrir las preferencias XML y leer las credenciales de inicio de sesión, pero eso no es un riesgo de seguridad porque el usuario conocía las credenciales para empezar.

Segundo caso: Intentar ocultar las credenciales de inicio de sesión del usuario

Este es el caso más complicado: el usuario no debe conocer las credenciales de inicio de sesión, pero aún necesita acceso a la base de datos. En este caso, el usuario que ejecuta la aplicación tiene acceso directo a la base de datos, lo que significa que el programa necesita conocer las credenciales de inicio de sesión antes de tiempo. La solución que mencioné anteriormente no es apropiada para este caso. Puede almacenar las credenciales de inicio de sesión de la base de datos en un archivo de preferencias, pero el usuario podrá leer ese archivo, ya que será el propietario. De hecho, realmente no hay una buena manera de utilizar este caso de una manera segura.

Caso correcto: Usando una arquitectura de varios niveles

La forma correcta de hacerlo es tener una capa intermedia, entre su servidor de base de datos y su aplicación cliente, que autentique usuarios individuales y permite realizar un conjunto limitado de operaciones. Cada usuario tendría sus propias credenciales de inicio de sesión, pero no para el servidor de base de datos. Las credenciales permitirían el acceso a la capa intermedia (el nivel de lógica de negocio) y serían diferentes para cada usuario.

Cada usuario tendría su propio nombre de usuario y contraseña, que podrían almacenarse localmente en un archivo de preferencias sin ningún riesgo de seguridad. Esto se llama una arquitectura de tres niveles (los niveles son su servidor de base de datos, servidor de lógica empresarial y aplicación cliente). Es más complejo, pero realmente es la forma más segura de hacer este tipo de cosas.

El orden básico de las operaciones es:

1. El cliente se autentica con el nivel de lógica de negocio utilizando el nombre de usuario/contraseña personal del usuario. El nombre de usuario y la contraseña son conocidos por el usuario y no están relacionados con las credenciales de inicio de sesión de la base de datos de ninguna manera.
2. Si la autenticación tiene éxito, el cliente realiza una solicitud a la nivel de lógica de negocio que pide cierta información de la base de datos. Por ejemplo, un inventario de productos. Tenga en cuenta que la solicitud del cliente no es una consulta SQL; es una llamada a un procedimiento remoto como getInventoryList.
3. El nivel de lógica de negocio se conecta a la base de datos y recupera la información solicitada. El nivel de lógica empresarial se encarga de formar una consulta SQL segura basada en la solicitud del usuario. Cualquier parámetro de la consulta SQL debe ser desinfectado para evitar la inyección SQL ataques.
4. El nivel de lógica de negocio envía la lista de inventario a la aplicación cliente.
5. El cliente muestra la lista de inventario al usuario.

Tenga en cuenta que en todo el proceso, la aplicación cliente nunca se conecta directamente a la base de datos. El nivel de lógica de negocio recibe una solicitud de un usuario autenticado, procesa la solicitud del cliente para una lista de inventario y solo entonces ejecuta una consulta SQL.