Как сохранить адрес хоста, имя пользователя и пароль базы данных и другую защищенную информацию при кодировании приложения на Java для этого приложения?

Question

Я разрабатываю автономное приложение на Java и MySql в качестве бэк-энда.Поскольку это приложение будет использоваться в профессиональных целях.Друзья У меня есть следующие вопросы в области кодирования.

Проблема 1: Поскольку мое приложение взаимодействует с базой данных по многим событиям на компонентах интерфейса, например, кнопкам, выпадающему списку и т. Д. При каждом событии либо данные выбираются из базы данных, либо сохраняются, либо изменяютсяв базу данных.поэтому в каждой точке я устанавливаю соединение с базой данных, выполняю запрос, снова закрываю соединение и делаю подготовленное состояние и набор результатов равным нулю.

Я хочу спросить экспертов, что это мой подход в соответствии с отрасльюстандарты или как начинающий программист?Пожалуйста, объясните, как мне выполнить код для соответствия отраслевым стандартам.

Проблема 2: В приведенном выше сценарии при подключении к базе данных требуются адрес хоста, имя пользователя и пароль.Мой вопрос: где мне хранить эту очень секретную и важную информацию?

A) Сначала я решил жестко закодировать их в исходном коде, чтобы никто не нашел и не понял.1. Но всякий раз, когда я хочу использовать это приложение для другой базы данных.Это каждый раз, когда мне нужно изменить вышеуказанную информацию в исходном коде и перекомпилировать исходный код и дать окончательный JAR для клиента.2. Один из моих друзей также сказал мне, что есть инструменты, которые преобразуют байт-код в исходный код, и любой может узнать эту информацию.Я не верю в такую ​​возможность, но просто ради объяснения проблемы я упоминаю этот момент здесь.

B) Во-вторых, я решил сохранить этот адрес хоста, имя пользователя и пароль в файле свойств.1. Но файл свойств доступен для чтения, и любой может извлечь файл jar, а также найти файл свойств и прочитать из него такую ​​ценную информацию.

Здесь я хочу спросить экспертов:и в соответствии с промышленными стандартами?б] Есть ли другое очень безопасное и гибкое решение для вышеуказанной проблемы?Пожалуйста, объясни мне это.Если другого решения не существует, то какое решение является безопасным и гибким в вышеуказанном случае.

Пожалуйста, помогите мне разобраться с проблемами, описанными выше.Спасибо.

Answer 1

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

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

Пример содержимого может быть:

myapp.db.username=foo
myapp.db.password=bar
myapp.db.dbname=some_db

etc

Answer 2

Это не имеет большого смысла.

Либо приложение должно подключаться к соседней базе данных - в этом случае оно находится вне вашего контроля, и локальный администратор БД будет иметь доступ к любой информации, хранящейся в нем, даже без имени пользователя / пароля, используемого приложением

... или ...

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

Таким образом, даже если бы существовал какой-то волшебный способ сохранить имя пользователя и пароль на клиенте, где он был доступен только для вашего приложения, это на самом деле не решило бы вашу проблему.

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

Answer 3

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

При использовании одного соединения ваши подготовленные операторы также будут оставаться действительными на протяжении всего сеанса и не будутдолжны быть воссозданы;это также сделает ваше приложение намного быстрее.

Что касается имени пользователя / пароля;почему бы не ввести их пользователю, когда они откроют ваше приложение, и тогда вам не о чем беспокоиться с точки зрения безопасности?