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

@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

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

Новые блоги и статьи Все статьи Все блоги /
Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .	Расчёт токов в цепи постоянного тока igorrr37 05.01.2026 / * Дана цепь постоянного тока с сопротивлениями и напряжениями. Надо найти токи в ветвях. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа и решает её. Последовательность действий:. . .	Новый CodeBlocs. Версия 25.03 palva 04.01.2026 Оказывается, недавно вышла новая версия CodeBlocks за номером 25. 03. Когда-то давно я возился с только что вышедшей тогда версией 20. 03. С тех пор я давно снёс всё с компьютера и забыл. Теперь. . .
Модель микоризы: классовый агентный подход anaschu 02.01.2026 Раньше это было два гриба и бактерия. Теперь три гриба, растение. И на уровне агентов добавится между грибами или бактериями взаимодействий. До того я пробовал подход через многомерные массивы,. . .	Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Programma_Boinc 28.12.2025 Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Налог на собак: https:/ / ********/ gallery/ V06K53e Финансовый отчет в Excel: https:/ / ********/ gallery/ bKBkQFf Пост отсюда. . .	Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Programma_Boinc 26.12.2025 Нашел на реддите интересную статью под названием Anyone know where to get a free Desktop or Laptop? Ниже её машинный перевод. После долгих разбирательств я наконец-то вернула себе. . .	Thinkpad X220 Tablet — это лучший бюджетный ноутбук для учёбы, точка. Programma_Boinc 23.12.2025 Рецензия / Мнение/ Перевод Нашел на реддите интересную статью под названием The Thinkpad X220 Tablet is the best budget school laptop period . Ниже её машинный перевод. Thinkpad X220 Tablet —. . .

Uswer 2282 / 1598 / 400 Регистрация: 26.06.2017 Сообщений: 4,726 Записей в блоге: 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 2282 / 1598 / 400 Регистрация: 26.06.2017 Сообщений: 4,726 Записей в блоге: 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 / 1070 / 148 Регистрация: 01.10.2009 Сообщений: 3,590 Записей в блоге: 1
	19.04.2024, 12:50
	Lasarex, да борода это всё 1

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