Как я могу защитить имя пользователя MySQL и пароль от декомпиляции?

Никогда пароли твердого кода в Ваш код. Это было недавно поднято в Лучшие 25 Самых Опасных Ошибок Программирования :

Жесткое кодирование секретная учетная запись и пароль в Ваше программное обеспечение чрезвычайно удобны - для квалифицированного, перепроектирует. Если пароль является тем же через все Ваше программное обеспечение, то каждый клиент становится уязвимым, когда тот пароль неизбежно становится известным. И потому что это трудно кодируется, это - огромная боль для фиксации.

необходимо сохранить конфигурационную информацию, включая пароли, в отдельном файле, который читает приложение, когда это запускается. Это - единственный реальный способ препятствовать тому, чтобы пароль просочился в результате декомпиляции (никогда не компилируют его в двоичный файл для начала).

Для получения дополнительной информации об этой частой ошибке, можно читать статья CWE-259. Статья содержит более полное определение, примеры и большую другую информацию о проблеме.

В Java, одном из самых легких способов сделать это должно использовать Предпочтительный класс. Это разработано для хранения всех видов настроек программы, некоторые из которых могли включать имя пользователя и пароль.

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
}

В вышеупомянутом коде, Вы могли звонить setCredentials метод после показа диалогового окна, просящего имя пользователя и пароль. Когда необходимо соединиться с базой данных, можно просто использовать getUsername и getPassword методы для получения сохраненных значений. Данные для входа в систему не будут трудно кодированы в Ваши двоичные файлы, таким образом, декомпиляция не изложит угрозу безопасности.

Важное Примечание: предпочтительные файлы являются просто текстовыми XML-файлами. Удостоверьтесь, что Вы делаете соответствующие шаги, чтобы препятствовать тому, чтобы неавторизованные пользователи просмотрели необработанные файлы (полномочия UNIX, полномочия Windows, и так далее). В Linux, по крайней мере, это не проблема, потому что вызов Preferences.userNodeForPackage создаст XML-файл в корневом каталоге текущего пользователя, который нечитаем другими пользователями так или иначе. В Windows ситуация могла бы отличаться.

Более важные Примечания: было большое обсуждение в комментариях этого ответа и других о том, что корректная архитектура для этой ситуации. Исходный вопрос действительно не упоминает контекст, в котором используется приложение, таким образом, я буду говорить об этих двух ситуациях, я могу думать. Первое имеет место, в котором человек, использующий программу уже, знает (и разрешен знать), учетные данные базы данных. Второе имеет место, в котором Вы, разработчик, пытаетесь держать учетные данные базы данных в секрете от человека, использующего программу.

Первый Случай: Пользователь разрешен знать данные для входа в систему базы данных

В этом случае, решение, которое я упомянул выше, будет работать. Класс Java Preference будет, сохранил имя пользователя и пароль в простом тексте, но предпочтительный файл только будет читаем авторизованным пользователем. Пользователь может просто открыть предпочтительный XML-файл и считать данные для входа в систему, но это не угроза безопасности, потому что пользователь знал учетные данные для начала.

1137-секундный Случай: Попытка скрыть данные для входа в систему от пользователя