Где лучше всего в программе хранить пароль от БД?

Есть 2 варианта:

1. Вынести пароль и ссылку к бд в dll который при необходимости будет обновляться.
2. Создать файл, с определенным методом шифрования и дешифрования (тут есть разные варианты реализации), а ключ к дешифровки хранить непосредственно в .exe файле.

Но лично я бы написал бы простой PHP скрипт на сервере, который бы обращался к базе данных. Если говорить про обычный хостинг, и у пользователя уже хранить в .exe статичную ссылку, а на сервере уже хранить пароль.

Мой ответ подразумевает, что речь идёт о локальной системе, т. е. клиентское приложение запускается на том же компьютере, где находится и СУБД, и БД.

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

Аргументы: 1) пароль не должен быть зашит в коде, чтобы его можно было менять; 2) пароль не должен быть доступен в открытом виде в конфигурационном файле.

Другого варианта нет. И этот вариант, как и любой другой, не защищён от реверс-инжиниринга.

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

Тут предлагают всякие варианты с хостингом, серверами и пр. интернетом, но в условии о доступе в сеть речи нет. Это может быть локальная база данных, которую нужно защитить от несанкционированного доступа пользователя. Это сразу отсекает метод защиты через аутентификацию средствами ОС. Защита БД осуществляется приложением, так как только приложение может менять БД и только запрограммированным образом, исключая риск намеренного или ненамеренного повреждения или изменения данных.

Появилась мысль, сам делал такое недавно. Исходя из гипотезы локального применения. Нужно защитить приложение от доступа. Сделать его в виде службы с Web-интерфейсом, приложение запускается от какой-то выделенной учётной записи, доступ к файлам и папкам приложения только у этой учётной записи (ну и система, и администраторы, понятно). Таким образом, нельзя будет изучить исполняемый файл приложения, его бибилиотеки, конфигурационные и другие файлы.

Естественно, всё это подразумевает, что пользователь не обладает правами администратора и не может получить административный доступ к системе.

С уточнёнными условиями неободимо сделать следующее:

1. доступ к БД осуществляет серверное backend-ПО;

2. клиентское приложение подключается к серверу с помощью учётных данных, которые пользователь вводит интерактивно.

Таким образом, в приложении и его конфигурационных файлах никакие пароли не хранятся.

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

Если нету посредника, который будет соединятся с базой - пароль в том или ином виде не может не быть на клиенте. Клиенту нужно использовать пароль чтоб установить соединение с БД.

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

Так же, под "БД" я представляю какую-то СУБД типа MySQL, где очень мало возможностей ограничения доступа.
Возможно, у вас другой движок БД, где сервер представляет всю нужную защиту данных и разграничение доступов, и ваша задача - именно спрятать пароль от соединения в обход клиентской программы.

Соответственно, ответ исходит из этой точки зрения.

Думаю, лучше всего хранить пароль - в зашифрованном виде в конфиге.

На счет шифрования - алгоритм должен быть проверенный временем, то есть например AES. Без велосипедов.

Ключ шифрования - частично захардкодить, частично вычислять в рантайме (например, операции над массивом). Так как компилятор может оптимизировать такой код, следует его написать так, чтоб компилятор не догадался, что результат будет константой. Очень хорошее решение - так же использовать идентификаторы привязанные к железу. Например, "Volume Serial Number" раздела, на котором лежит программа. Тогда даже если скопировать программу на флешку - он не будет работать.

Ну и всю эту красоту прогнать через HMAC.

Еще один мелкий лайфхак обфускации: прогнать base64 через шифр цезаря =)

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

Если бд на сервере, то сервер должен выполнять с ней работу => все логины и пароли должны храниться на сервере. Программа же должна общаться с сервером посредством запросов, в которых передаются данные, с которыми мы хотим что-то сделать

Сам пароль лучше не хранить нигде , только хеш , в крайнем случаее evn

Не храните пароль в программе. Заставьте пользователя зарегистрироваться - создать свои логин и пароль. Дальше пользователь введя их получает временный одноразовый для подключения. OAuth, JWT используют чаще всего. Если программка рассчитана на узкий круг и не интересна в глобальном плане, то хотя бы сделайте отдельную учётку для пользователя только с нужными правами и пусть он сам хранит свой пароль.