Как безопасно хранить пароль от базы данных?

@contempio · Регистрация: 28.03.2023

Студворк — интернет-сервис помощи студентам

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

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
using MySql.Data.MySqlClient;
 
namespace AuthForm
{
    class DataBase
    {
        MySqlConnection connection = new MySqlConnection("server=localhost;port=3306;username=root;password=root;database=AuthDataMyClient"); 
 
// Пояснение для форумчан...root/root не смейтесь, это просто дефолтная бд локального сервера, поменять пароль и логин 
от нее не могу, тк запускал со стороннего клиента - MAMP.
 
        public void OpeningConnection() // Открытие соеденения
        {
            if (connection.State == System.Data.ConnectionState.Closed)
                connection.Open();
        }
 
        public void ClosingConnection() // Закрытие соеденения
        {
            if (connection.State == System.Data.ConnectionState.Open)
                connection.Close();
        }
 
        public MySqlConnection GetСonnectionStatus() // Получаем статус соединения
        {
            return connection;
        }
    }
}

Говнокод буду переделывать со временем получения должного опыта. Опираясь на Ваш опыт, старожилы форума - хотелось бы услышать подсказку или ответ как.
Неважная лирика: пароли в базу я передаю в хешированом виде, sha512, соль пока не интегрировал
Я думаю, что можно как-то хранить в app.config, сделал так

XML
1
2
3
4
5
6
<?xml version="1.0"?>
<configuration>
  <connectionStrings>
    <add name="MyConnectionString" connectionString="server=localhost;port=3306;username=root;password=root;database=AuthDataMyClient"/>
  </connectionStrings>
</configuration>

Но хмл вроде бы легко читаем, может быть не так надо

Uswer · 29.03.2023, 21:10

По большому счёту в .Net коде вообще ничего спрятать нельзя, т.к. декомпиляторы хорошо развиты и позволяют даже обфусцированный код делать читаемым, но сейчас не об этом. То есть прятать данные и методы их извлечения в коде бессмысленно. Однако для защиты от дурака можно прибегнуть к любому более или менее стойкому методу шифрования. В этом случае строка подключения не будет светится в явном виде, но при этом она остаётся в коде и всё ещё доступна для хакинга. Как один из надёжных вариантов хранения предложу строку подключения, а возможно и другие секретные данные, хранить, например, в запароленном RAR-архиве рядом с программой. Для получения строки подключения необходима авторизация пользователя (пускай даже локальная) и по его (вводимым им) авторизационным данным (они же пароль от архива или некая его часть) извлекайте файл с данными из архива. Таким образом, без ввода данных пользователем извлечение строки подключения становится практически невозможным.
Сложность пароля и время его подбора, а также методы утечки пароля не рассматриваем, т.к. это отдельная и довольно избитая тема.

@contempio · 29.03.2023, 22:04 **[ТС]**

Uswer, спасибо за ваш ответ. По всей видимости будет проблематично это сделать

Читал в документации, что можно конфиг зашифровать встроенной утилитой в студию...

@Usaga · 30.03.2023, 04:10

Сообщение от contempio

где хранить конфиг от бд MySQL (7 строчка кода)?

Рядом с вашим приложением. По-хорошему, ваше приложение должно иметь клиент-серверную архитектуру. В базу должна ходить серверная часть, она же и будет знать о паролях всяких. На сервере можно не париться сокрытием паролей. На клиенте же никаких паролей быть не должно в таком случае.

Но если у вас клиент напрямую в базу ломится... Тут никакое шифрование не спасёт, ибо на клиенте всё и расшифровать можно как нефиг делать.

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

@Wolfdp · 30.03.2023, 08:53

Если вы единственный пользователь своего приложения, и connectionString статический -- зашейте в exe и забейте. Но по фешную конечно подымать сервис (например WebAPI), который и будет "защищать" БД от внешнего проникновения.

@Andrey-MSK · 30.03.2023, 11:34

Сообщение от contempio

Code
1
server=localhost;port=3306;username=root;password=root;database=AuthDataMyClient

В App.config

XML
1
2
3
4
<connectionStrings>
    <add name="SQLConnectDebug" 
         connectionString="server=localhost;port=3306;username={0};password={1};database=AuthDataMyClient" />      
</connectionStrings>

И в коде подставляйте туда данные из окна входа в приложение.

Uswer · 30.03.2023, 16:14

Andrey-MSK, ну как бы не совсем хорошо, чтобы конечный пользователь знал учётные данные от SQL-сервера. То, что приложение не клиент-серверное безусловно минус. Однако, если предполагается его использование в рамках одной сети предприятия, то почему бы и не использовать сетевые возможности SQL-сервера. А если приглядеться, то можно заметить server=localhost, что вообще говорит о локальном сервере. Тогда встаёт вопрос - от кого ТС прячет учётные данные сервера?
Выше я перегнул палку с архивом, думаю что будет достаточно внедрить в проект методы шифрования/дешифрования учётных данных, где в качестве ключа шифрования будет выступать пароль пользователя (или его хеш). Вот готовый пример такого шифрования.

@Andrey-MSK · 30.03.2023, 17:13

Сообщение от Uswer

в рамках одной сети предприятия, то почему бы и не использовать сетевые возможности SQL-сервера

Я так и делаю у себя, у меня стоит аутентификация Windows и все пользователи спокойно подключаются к своим учеткам на сервере, но это про MS SQL Server, а у ТС MySQL... Я не уверен что там такое есть...

Добавлено через 48 минут

Сообщение от Uswer

ну как бы не совсем хорошо, чтобы конечный пользователь знал учётные данные от SQL-сервера.

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

@contempio · 01.04.2023, 15:24 **[ТС]**

Однако, если предполагается его использование в рамках одной сети предприятия, то почему бы и не использовать сетевые возможности SQL-сервера. А если приглядеться, то можно заметить server=localhost, что вообще говорит о локальном сервере. Тогда встаёт вопрос - от кого ТС прячет учётные данные сервера?

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

@Wolfdp · 01.04.2023, 22:42

contempio, если не секрет, то что за приложение? Просто в зависимости от назначения БД, возможно вам вообще ближе будет какой-нибудь sqlite для портативности. Либо наоборот таки нужно полноценный отдельный сервис.

@contempio · 02.04.2023, 18:02 **[ТС]**

Неко с ушами, ну никакое пока что, планировал как-нибудь интегрировать форму с дальнейшим проектом, но пока не нацелился на какой. Делаю по мелочи, учусь, мелкие формы на 200-300 строк...
Просто попал на канал недо-прогера - Дударя, он там говнокодил, но показал основные классы для работы с бд. Я не стал заморачиваться и взял как он MySql.
В дальнейшем пересяду на Azure || MS SQL Server

@Wolfdp · 02.04.2023, 23:52

Сообщение от contempio

ну никакое пока что

Тогда нефиг страдать.

Общий подход такой:
- если много пользователей, и укаждого свой уровень доступа, то подымается отдельный сервис с публичным API (web api, rest, wcf, gRPC. Возможно стоит смотреть в сторону последнего, правда тут уверености нет). Приложение ничего не знает о БД, и работает только с публичным API. Сам сервис либо на отдельной машине, либо на той, где админу-учетка под паролем, и юзера не могут зайти на папку где расположен сам сервис.
- если пользователь один (например база игр на ПК аля steam или меседжер), то тогда как правило используется гораздо "проще" БД, например sqlite. Опционально можно шифровать БД или содержимое через пароль, который вводит пользователь.
- опять же исходя из задачи, могут менятся подходы от "таки используем полновесную СУБД" до "фигачим тупо в файл".

Добавлено через 12 минут

Не по теме:

Сообщение от contempio

Просто попал на канал недо-прогера - Дударя, он там говнокодил, но показал основные классы для работы с бд.

После ознакомления с этим чудом, вспомнилась хохма: вот цифры от 0 до 9, вот знаки плюс и минус. Задание -- найдите логорифмический интеграл из мнимого корня от лямда-фи.

Добавлено через 4 минуты

Не по теме:

окей, беру слова обратно -- он реально не шарит.

@Usaga · 03.04.2023, 04:00

Сообщение от contempio

В дальнейшем пересяду на Azure || MS SQL Server

Зачем MS SQL Server, когда тот же Azure работает и с MySQL и с Postgres?

@Lasarex · 19.04.2024, 10:06

Вопрос был задан давно, но все же отвечу, вдруг ком-то пригодится.
Хранить строку подключения и в частности пароли в коде нельзя, это небезопасно. То же самое относится и к хранению этих данных в файле App.config, который также копируется в открытом виде в каталог приложения при компиляции.
Кроме того, для тех кто пользуется системами контроля версий, например git, все эти секреты копируются в репозиторий, что также не есть хорошо.
Наиболее безопасно хранить секреты в отдельном config файле за пределами каталога проекта и рабочего каталога приложения. А вот ссылку на этот файл уже указывать в файле App.config.

Пример App.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings file="C:\config\MyAppOptions.config">
<add key="MyOpenKey" value="0" />
</appSettings>
</configuration>

В этом примере секция appSettings содержит открытое значение ключа MyOpenKey, и ссылку на файл за пределами проекта MyAppOptions.config, значения которого приложение автоматом подтягивает из этого файла в процессе работы.

Пример MyAppOptions.config

<?xml version="1.0" encoding="utf-8" ?>
<appSettings>
<add key="connectionString" value="server=localhost;port=3306;userna me={0};password={1};database=AuthDataMyC lient" />
</appSettings>

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

@XIST · 19.04.2024, 12:50

Lasarex, да борода это всё

@Andrey-MSK · 19.04.2024, 12:52

Сообщение от Lasarex

Пример App.config

Сообщение от Lasarex

Пример MyAppOptions.config

А зачем два файла? Чем один не устраивает с такой же строкой?

@Lasarex · 19.04.2024, 14:44

Сообщение от Andrey-MSK

А зачем два файла? Чем один не устраивает с такой же строкой?

Вот ссылка на официальную документацию зачем два файла.

https://learn.microsoft.com/ru... -and-azure

@Wolfdp · 19.04.2024, 18:14

Сообщение от Lasarex

Хранить строку подключения и в частности пароли в коде нельзя, это небезопасно.

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

Зашивать строку подключения в код не стоит по немного другим причинам -- это неудобно в использовании.

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

@wizard41 · 19.04.2024, 19:51

Ну вот реально - вопрос на уровне "фантазий" и знаний отвечающих, не приводящих в конечном итоге ни к чему. Так, поболтать, видимо.
Все просто на самом деле - если у ТСа база локальная, то не фиг парится. А если действительно там "что-то эдакое", то следуй общепринятым подходам, которые здесь, от части, тоже были озвучены.

Новые блоги и статьи Все статьи Все блоги /
PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Как объединить две одинаковые БД Access с разными данными VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .
Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .

Uswer 2281 / 1597 / 400 Регистрация: 26.06.2017 Сообщений: 4,723 Записей в блоге: 1
	29.03.2023, 21:10
	По большому счёту в .Net коде вообще ничего спрятать нельзя, т.к. декомпиляторы хорошо развиты и позволяют даже обфусцированный код делать читаемым, но сейчас не об этом. То есть прятать данные и методы их извлечения в коде бессмысленно. Однако для защиты от дурака можно прибегнуть к любому более или менее стойкому методу шифрования. В этом случае строка подключения не будет светится в явном виде, но при этом она остаётся в коде и всё ещё доступна для хакинга. Как один из надёжных вариантов хранения предложу строку подключения, а возможно и другие секретные данные, хранить, например, в запароленном RAR-архиве рядом с программой. Для получения строки подключения необходима авторизация пользователя (пускай даже локальная) и по его (вводимым им) авторизационным данным (они же пароль от архива или некая его часть) извлекайте файл с данными из архива. Таким образом, без ввода данных пользователем извлечение строки подключения становится практически невозможным. Сложность пароля и время его подбора, а также методы утечки пароля не рассматриваем, т.к. это отдельная и довольно избитая тема. 1

@contempio 1 / 1 / 0 Регистрация: 28.03.2023 Сообщений: 52
	29.03.2023, 22:04 [ТС]
	Uswer, спасибо за ваш ответ. По всей видимости будет проблематично это сделать Читал в документации, что можно конфиг зашифровать встроенной утилитой в студию... 0

@Wolfdp 3789 / 1766 / 371 Регистрация: 15.06.2012 Сообщений: 6,543 Записей в блоге: 3
	30.03.2023, 08:53
	Если вы единственный пользователь своего приложения, и connectionString статический -- зашейте в exe и забейте. Но по фешную конечно подымать сервис (например WebAPI), который и будет "защищать" БД от внешнего проникновения. 0

Uswer 2281 / 1597 / 400 Регистрация: 26.06.2017 Сообщений: 4,723 Записей в блоге: 1
	30.03.2023, 16:14
	Andrey-MSK, ну как бы не совсем хорошо, чтобы конечный пользователь знал учётные данные от SQL-сервера. То, что приложение не клиент-серверное безусловно минус. Однако, если предполагается его использование в рамках одной сети предприятия, то почему бы и не использовать сетевые возможности SQL-сервера. А если приглядеться, то можно заметить `server=localhost`, что вообще говорит о локальном сервере. Тогда встаёт вопрос - от кого ТС прячет учётные данные сервера? Выше я перегнул палку с архивом, думаю что будет достаточно внедрить в проект методы шифрования/дешифрования учётных данных, где в качестве ключа шифрования будет выступать пароль пользователя (или его хеш). Вот готовый пример такого шифрования. 0

@Wolfdp 3789 / 1766 / 371 Регистрация: 15.06.2012 Сообщений: 6,543 Записей в блоге: 3
	01.04.2023, 22:42
	contempio, если не секрет, то что за приложение? Просто в зависимости от назначения БД, возможно вам вообще ближе будет какой-нибудь sqlite для портативности. Либо наоборот таки нужно полноценный отдельный сервис. 0

@contempio 1 / 1 / 0 Регистрация: 28.03.2023 Сообщений: 52
	02.04.2023, 18:02 [ТС]
	Неко с ушами, ну никакое пока что, планировал как-нибудь интегрировать форму с дальнейшим проектом, но пока не нацелился на какой. Делаю по мелочи, учусь, мелкие формы на 200-300 строк... Просто попал на канал недо-прогера - Дударя, он там говнокодил, но показал основные классы для работы с бд. Я не стал заморачиваться и взял как он MySql. В дальнейшем пересяду на Azure \|\| MS SQL Server 0

@Lasarex 8 / 7 / 1 Регистрация: 01.08.2019 Сообщений: 6
	19.04.2024, 10:06
	Вопрос был задан давно, но все же отвечу, вдруг ком-то пригодится. Хранить строку подключения и в частности пароли в коде нельзя, это небезопасно. То же самое относится и к хранению этих данных в файле App.config, который также копируется в открытом виде в каталог приложения при компиляции. Кроме того, для тех кто пользуется системами контроля версий, например git, все эти секреты копируются в репозиторий, что также не есть хорошо. Наиболее безопасно хранить секреты в отдельном config файле за пределами каталога проекта и рабочего каталога приложения. А вот ссылку на этот файл уже указывать в файле App.config. Пример App.config <?xml version="1.0" encoding="utf-8" ?> <configuration> <appSettings file="C:\config\MyAppOptions.config"> <add key="MyOpenKey" value="0" /> </appSettings> </configuration> В этом примере секция appSettings содержит открытое значение ключа MyOpenKey, и ссылку на файл за пределами проекта MyAppOptions.config, значения которого приложение автоматом подтягивает из этого файла в процессе работы. Пример MyAppOptions.config <?xml version="1.0" encoding="utf-8" ?> <appSettings> <add key="connectionString" value="server=localhost;port=3306;userna me={0};password={1};database=AuthDataMyC lient" /> </appSettings> При установке приложения у пользователя, необходимо будет добавить этот файл по указанному в App.config пути. В итоге мы: - не храним секреты в проекте, - имеем для каждой установки приложения свою строку подключения, которая не меняется при обновлении. 0

@XIST 1960 / 1061 / 148 Регистрация: 01.10.2009 Сообщений: 3,589 Записей в блоге: 1
	19.04.2024, 12:50
	Lasarex, да борода это всё 1

@wizard41 3388 / 2707 / 574 Регистрация: 04.09.2018 Сообщений: 8,521 Записей в блоге: 3
	19.04.2024, 19:51
	Ну вот реально - вопрос на уровне "фантазий" и знаний отвечающих, не приводящих в конечном итоге ни к чему. Так, поболтать, видимо. Все просто на самом деле - если у ТСа база локальная, то не фиг парится. А если действительно там "что-то эдакое", то следуй общепринятым подходам, которые здесь, от части, тоже были озвучены. 0