Никогда не вставляйте пароли в свой код жестко. Это недавно было внесено в список 25 самых опасных ошибок программирования :
Жесткое кодирование секретной учетной записи и пароля в вашем программном обеспечении чрезвычайно удобно - для опытных инженеров-реверс-инженеров. Если пароль один и тот же для всего вашего программного обеспечения, тогда каждый клиент становится уязвимым, когда этот пароль неизбежно становится известен. И поскольку это жестко запрограммировано, исправить это очень сложно.
Вы должны хранить информацию о конфигурации, включая пароли, в отдельном файле, который приложение читает при запуске. Это единственный реальный способ предотвратить утечку пароля в результате декомпиляции (никогда не компилируйте его в двоичный файл для начала).
Подробнее об этой распространенной ошибке вы можете прочитать в статье CWE-259 . В статье содержится более подробное определение, примеры и много другой информации о проблеме.
В Java один из самых простых способов сделать это - использовать класс Preferences. Он предназначен для хранения всевозможных настроек программы, некоторые из которых могут включать имя пользователя и пароль.
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);
}
}
В приведенном выше коде вы можете вызвать setCredentialsметод после отображения диалогового окна с запросом имени пользователя и пароля. Если вам необходимо подключиться к базе данных, вы можете просто использовать getUsernameи getPasswordметоды для получения сохраненных значений. Учетные данные для входа в систему не будут жестко закодированы в ваших двоичных файлах, поэтому декомпиляция не представляет угрозы безопасности.
Важное примечание: файлы настроек - это просто текстовые XML-файлы. Убедитесь, что вы предприняли соответствующие шаги для предотвращения просмотра неавторизованных пользователей неавторизованных файлов (разрешения UNIX, разрешения Windows и т. Д.). В Linux, по крайней мере, это не проблема, потому что при вызове создается Preferences.userNodeForPackageXML-файл в домашнем каталоге текущего пользователя, который в любом случае не читается другими пользователями. В Windows ситуация может быть иной.
Более важные примечания: в комментариях к этому и другим ответам было много обсуждений о том, какая архитектура является правильной для этой ситуации. В исходном вопросе на самом деле не упоминается контекст, в котором используется приложение, поэтому я расскажу о двух ситуациях, которые могу придумать. Первый - это случай, когда человек, использующий программу, уже знает (и имеет право знать) учетные данные базы данных. Во втором случае вы, разработчик, пытаетесь сохранить в секрете учетные данные базы данных от лица, использующего программу.
Первый случай: пользователю разрешено знать учетные данные для входа в базу данных
В этом случае сработает решение, о котором я говорил выше. Класс Java Preferenceбудет хранить имя пользователя и пароль в виде обычного текста, но файл настроек будет доступен для чтения только авторизованному пользователю. Пользователь может просто открыть XML-файл настроек и прочитать учетные данные для входа в систему, но это не представляет угрозы для безопасности, поскольку пользователь изначально знал учетные данные.
Второй случай: попытка скрыть учетные данные для входа от пользователя
Это более сложный случай: пользователь не должен знать учетные данные для входа, но ему по-прежнему нужен доступ к базе данных. В этом случае пользователь, запускающий приложение, имеет прямой доступ к базе данных, что означает, что программе необходимо заранее знать учетные данные для входа. Упомянутое выше решение не подходит для этого случая. Вы можете сохранить учетные данные для входа в базу данных в файле настроек, но пользователь сможет читать этот файл, поскольку он будет владельцем. На самом деле, на самом деле нет хорошего способа безопасного использования этого кейса.
Правильный случай: использование многоуровневой архитектуры
Правильный способ сделать это - создать промежуточный уровень между сервером базы данных и клиентским приложением, который аутентифицирует отдельных пользователей и позволяет выполнять ограниченный набор операций. У каждого пользователя будут свои собственные учетные данные для входа, но не для сервера базы данных. Учетные данные позволят получить доступ к среднему уровню (уровню бизнес-логики) и будут разными для каждого пользователя.
У каждого пользователя будет собственное имя пользователя и пароль, которые можно будет хранить локально в файле настроек без какого-либо риска для безопасности. Это называется трехуровневой архитектурой (уровни - это ваш сервер базы данных, сервер бизнес-логики и клиентское приложение). Это более сложный, но на самом деле наиболее безопасный способ делать подобные вещи.
Основной порядок действий:
- Клиент аутентифицируется с помощью уровня бизнес-логики, используя личное имя пользователя и пароль. Имя пользователя и пароль известны пользователю и никак не связаны с учетными данными для входа в базу данных.
- Если аутентификация прошла успешно, клиент делает запрос к уровню бизнес-логики, запрашивая некоторую информацию из базы данных. Например, инвентаризация продуктов. Обратите внимание, что запрос клиента не является запросом SQL; это удаленный вызов процедуры, такой как
getInventoryList.
- Уровень бизнес-логики подключается к базе данных и получает запрошенную информацию. Уровень бизнес-логики отвечает за формирование безопасного SQL-запроса на основе запроса пользователя. Любые параметры SQL-запроса должны быть очищены, чтобы предотвратить атаки SQL-инъекций.
- Уровень бизнес-логики отправляет список инвентаризации обратно в клиентское приложение.
- Клиент отображает список инвентаря пользователю.
Обратите внимание, что в течение всего процесса клиентское приложение никогда не подключается напрямую к базе данных . Уровень бизнес-логики получает запрос от аутентифицированного пользователя, обрабатывает запрос клиента на список инвентаризации и только после этого выполняет SQL-запрос.