Как хранить пароль в конфигурационном файле
Обновлено: 04.07.2024
У меня есть программа, которая считывает информацию о сервере из файла конфигурации и хотела бы зашифровать пароль в этой конфигурации, который может быть прочитан моей программой и расшифрован.
- зашифровать пароль открытого текста, который будет храниться в файле
- расшифровать зашифрованный пароль, считанный из файла из моей программы
любые рекомендации о том, как я буду это делать? Я думал написать свой собственный но я чувствую, что это было бы ужасно небезопасно.
простой способ сделать это-использовать шифрование на основе пароля в Java. Это позволяет шифровать и расшифровывать текст с помощью пароля.
это в основном означает инициализацию javax.crypto.Cipher алгоритм "AES/CBC/PKCS5Padding" и получение ключа от javax.crypto.SecretKeyFactory С .
вот пример кода (обновлен, чтобы заменить менее безопасный вариант на основе MD5):
остается одна проблема: где вы должны хранить пароль, который вы используете для зашифровать пароли? Вы можете сохранить его в исходном файле и запутать его, но найти его снова не так сложно. Кроме того, вы можете дать его как системное свойство при запуске процесса Java ( -DpropertyProtectionPassword=. ).
та же проблема остается, если вы используете хранилище ключей, которое также защищено паролем. В принципе, вам нужно будет иметь один мастер-пароль где-то, и его довольно сложно защитить.
Да, определенно не пишите свой собственный алгоритм. Java имеет много криптографических API.
Если ОС, на которой вы устанавливаете, имеет хранилище ключей, вы можете использовать его для хранения криптографических ключей, которые вам понадобятся для шифрования и дешифрования конфиденциальных данных в вашей конфигурации или других файлах.
проверить jasypt, которая является библиотекой, предлагающей основные возможности шифрования с минимальными усилиями.
Я думаю, что лучшим подходом является обеспечение того, чтобы ваш файл конфигурации (содержащий ваш пароль) был доступно только для конкретной учетной записи пользователя. Например, у вас может быть конкретный пользователь приложения appuser к которому только доверенные люди имеют пароль (и к которому они su to).
таким образом, нет никаких раздражающих криптографических накладных расходов, и у вас все еще есть пароль, который является безопасным.
EDIT: Я предполагаю, что вы не экспортируйте конфигурацию приложения вне доверенной среды (что, я не уверен, имело бы смысл, учитывая вопрос)
ну, чтобы решить проблемы мастер-пароля-лучший подход не хранить пароль в любом месте, приложение должно шифровать пароли для себя-так что только он может расшифровать их. Так что, если бы я использовал a .конфигурационный файл я бы сделал следующее,mySettings.config:
encryptTheseKeys=секретный ключ, anotherSecret
secretKey=unprotectedPasswordThatIputHere
anotherSecret=anotherPass
someKey=unprotectedSettingIdontCareAbout
поэтому я бы прочитал в ключах, которые упомянуты в encryptTheseKeys, применить пример Brodwalls сверху на них и запишите их обратно в файл с помощью какого-либо маркера (скажем склеп:) чтобы приложение знало, что больше этого не делать, вывод будет выглядеть так:
encryptTheseKeys=секретный ключ, anotherSecret
secretKey=крипта:ii4jfj304fjhfj934fouh938
anotherSecret=крипта: jd48jofh48h
someKey=unprotectedSettingIdontCareAbout
просто убедитесь, что оригиналы хранятся в вашем собственном безопасном месте.
самое главное, и слон в комнате, и все такое, это если ваше приложение может получить пароль, то хакер с доступом к коробке может получить его тоже!
единственный способ обойти это - приложение запрашивает "мастер-пароль" на консоли с использованием стандартного ввода, а затем использует его для расшифровки паролей, хранящихся в файле. Конечно, это полностью делает невозможным запуск приложения без присмотра вместе с ОС, когда она загружается.
однако, даже с этим уровнем раздражения, если хакеру удается получить root-доступ (или даже просто доступ в качестве пользователя, запускающего ваше приложение), он может сбросить память и найти пароль там.
дело в том, чтобы не позволить всей компании иметь доступ к производственному серверу (и, следовательно, к паролям), и убедитесь, что невозможно взломать этот ящик!
попробуйте использовать методы шифрования ESAPIs. Его легко настроить, и вы также можете легко изменить свои ключи.
1)шифровать 2)расшифровать 3)Знак 4)удалить подпись 5)хеширование 6) подписи на основе времени и многое другое только с одной библиотекой.
посмотрите, что доступно в Jetty для хранения пароля (или хэшей) в файлах конфигурации, и подумайте, может ли кодировка OBF быть полезной для вас. Затем посмотрите в источнике, как это делается.
Если вы не слишком боитесь расшифровки пароля, и его можно очень просто настроить с помощью компонента для хранения ключа пароля. Однако, если вам нужна дополнительная безопасность, вы можете установить переменную среды с секретом и удалить ее после запуска. С этим вы должны беспокойтесь о том, что приложение / сервер идет вниз, а не приложение не автоматически перезапускается.
если вы используете в Java 8 использование внутреннего кодера и декодера Base64 можно избежать, заменив
return new BASE64Encoder().encode(bytes);
return new BASE64Decoder().decodeBuffer(property);
обратите внимание, что это решение не защищает ваши данные, поскольку методы дешифрования хранятся в одном месте. Это только затрудняет разрыв. Главным образом оно избегает напечатать его и показать всем по ошибке.
Навеяно обнаруженной недавно критической уязвимостью в одном из фреймворков, который, правда, ещё не релизнулся: Был доступен просмотр любых файлов проекта, в том числе, конфигурационного файла. А в нём - ключ, которым подписывается сессия (и по умолчанию хранится только в Cookie), а так же некоторые хранят там данные для подключения к БД. В связи с этим вопрос, где таки хранить данные для подключения к БД и др. подобные вещи? В переменных среды? Или таки нужно вместо паролей использовать ещё что?
man криптография // thread
не в открытом доступе, ели есть физический доступ к файлам программы, то уже можно не рыпаться
а субд должно торчать только в локалхост
Так-с. В чём профит криптографии для хранения данных подключения к БД в случае, когда все файлы проекта оказались доступны публично?
Слушай, либо ты читаешь хотя бы историю и понимаешь зачем и почему что-то придумали. Либо не занимаешься этими вопросами вообще. Даже не подходи к компьютерам.
Коротко ответ на твой вопрос:
В связи с этим вопрос, где таки хранить пароли? В переменных среды? Или таки нужно вместо паролей использовать ещё что?
Где угодно. Важно зашифровать пароли стойким алгоритмом. Если на взлом шифра требуется несколько лет этого уже более чем достаточно в 95% случаях.
Последнее исправление: gh0stwizard 22.02.14 15:49:17 (всего исправлений: 1)
а субд должно торчать только в локалхост
Согласен, что в случае, если наш web сервис и БД находятся на одном физическом сервере, то БД в Интернеты смотреть не должна. Но не всегда это так.
Друг мой, ты говоришь не о том. Вот тебе конспект:
Был доступен просмотр . конфигурационного файла. . некоторые хранят там данные для подключения к БД
Поскольку ты изменил вопрос уже после. и теперь это что-то вменяемое, отвечаю.
В связи с этим вопрос, где таки хранить данные для подключения к БД и др. подобные вещи? В переменных среды? Или таки нужно вместо паролей использовать ещё что?
Ответ на этот вопрос хорошо описан у Эрика Рэймонда. По сути все эти пароли security by obscurity. Рассмотрим случай, когда пароль передается через параметры запуска программы: $ ps xawu выдаст нам результат. Любые манипуляции с файлами, до которых есть доступ у текущего процесса дадут результат.
Более сложные схемы:
- Две базы: в одной ключи, в другой данные
- Hardware-based: удаленный ввод пароля/шифра, usb-ключи, сканеры сетчатки глаза и т.п.
И тем не менее, данные из самого процесса можно извлечь. Следовательно все, чем оперирует процесс надо шифровать, а ключ еще раз шифровать. и так до бесконечности.
Для поделий на гитхабе текущая схема проекта идеальна: она проста, удобна, не жрет лишних ресурсов и проверена временем. То, что нашли дыру — критичный баг, который закроют и все будет чики пуки. ИМХО, это напоминает возрождение Joomla, которая несла, несет и будет нести в себе подобные баги, ибо это не лечится :)
Поскольку ты изменил вопрос уже после. и теперь это что-то вменяемое
Это было вменяемым с самого начала (заметь, первый комментатор всё понял правильно). Вопрос был отредактирован для Ъ, читающих только заголовок и последнее предложение.
Ссылка на хорошо описанный ответ точно верна? Ничего подобного не нашёл, кроме нескольких предложений о том, что автор не хотел давать ложного чувства безопасности пользователям, поэтому не предусмотрел возможности шифровать паролей, и заключения в виде:
Система безопасности надежна, пока надежны ее секреты. Избегайте псевдо-секретов.
Любые манипуляции с файлами, до которых есть доступ у текущего процесса дадут результат.
Если есть доступ к выполнению произвольных команд от имени процесса - это конечно уже фейл и с этим ничего не поделаешь. Но в стартовом посте была ссылка на уязвимость, которая позволяла лишь смотреть системные файлы вне public директории (а это только config файл).
Как вывести свою систему на новый уровень безопасности с модулями python-gnupg и getpass4.
Изображение : freeGraphicToday, via Pixabay. CC0.
В условиях растущих требований к безопасности создание и хранение паролей может вызвать вопросы не только для пользователей, но и у разработчиков и системных администраторов. Специалисты и другие осведомлённые люди знают, что пароли нужно хранить в зашифрованном виде. Уже на этапе ввода символы пароля нужно скрывать от любых глаз (даже от того человека, который его вводит). Всегда ли мы можем выполнить хотя бы эти требования?
Я единственный пользователь своего ноутбука, а на его борту крутится ОС семейства Linux. Поэтому меня не беспокоят пользователи, которые могут случайно или неслучайно посмотреть мои конфигурационные файлы, работая на этом же компьютере. Я решил заморочиться и повысить безопасность своего личного ноутбука, и на то есть свои причины. Да, я шифрую свой домашний каталог, но как только вхожу в систему, любой пароль, хранящийся в виде простого текста в файле конфигурации, потенциально может быть уязвим для чересчур любопытных глаз.
К тому же, я использую почтовый клиент Mutt. Он позволяет мне читать и составлять электронные письма прямо в Linux-терминале. Мне удобно, мне нравится. Правда, ему нужно, чтобы я хранил пароль в файле конфигурации (.mutt), либо всё время вводил пароль в интерактивном режиме. Поэтому я ограничил права доступа к моему конфигурационному файлу Mutt, чтобы его мог видеть только я.
Но есть ещё один важный момент: я периодически пишу технические статьи, составляю туториалы, помогаю людям в сообществе и публикую много своего кода в общедоступных репозиториях, публикую скриншоты своего экрана, часто показываю что-то на примере своей рабочей системы. Если по недосмотру меня угораздит засветить в Интернете (или где-то ещё) данные (и в том числе пароли) из моих конфигурационных файлов, это бросит неприятную тень на мою репутацию и безопасность. Так что надо подстраховаться.
Ну и, если вдруг злоумышленник завладеет моим ноутбуком или каким-то другим образом получит доступ в систему, он не сможет получить мой пароль без боя, просто запустив cat для просмотра логов и конфигов.
Поиск решения задачи
Я решил, что лучший способ защитить мой пароль в Mutt — ввести пароль с клавиатуры, сохранить его в зашифрованном файле GPG, написать на Python скрипт расшифровки для моего GPG-пароля, ну и заодно обеспечить передачу пароля Mutt в скрипт offlineimap, который я использую для локальной синхронизации моего ноутбука с почтовым сервером.
Из подзаголовка статьи ясно, что я буду использовать модули python-gnupg и getpass. Модуль Python python-gnupg — это обёртка для инструмента шифрования gpg. Учтите, python-gnupg не следует путать с модулем под названием gnupg. GnuPG (GPG) — это утилита шифрования для Linux, и я использую её с 2009 года или около того. С ней я чувствую себя комфортно и верю в её безопасность.
Получить пользовательский ввод с помощью Python довольно просто. Вы вызываете input, и всё, что введёт пользователь сохраняется в переменной:
И в этом случае есть одна громадная проблема: когда я ввожу пароль в терминале, всё, что я набираю, видно всем, кто смотрит через моё плечо или просматривает историю моего терминала:
Написание скрипта с python-gnupg и getpass
Как это часто бывает, ничего самому писать не надо, потому что уже существует модуль Python, который позволяет решить проблему. Это модуль getpass4. С точки зрения пользователя он ведёт себя точно так же, как любое стандартное приглашение к вводу, за исключением того, что не отображает введённые символы.
Установим оба модуля с помощью pip:
У меня получился вот такой скрипт для создания пароля с невидимым вводом и расшифровкой:
Сохраните файл как password_prompt.py, если хотите попробовать скрипт у себя. Если вместе с ним вы хотите использовать offlineimap, укажите в конфигурационном файле .offlineimaprc имя и путь к скрипту с паролем (у меня это
/.mutt/password_prompt.py). Правда, там нужно сделать ещё кое-что, но об этом позже.
Тестирование скрипта с gpg
Надеюсь, у вас уже установлен gpg, так как сейчас мы будем создавать зашифрованный файл пароля и тестировать скрипт.
Запускаем созданный ранее скрипт:
/.mutt/pass.gpg. Значит, скрипт работает правильно.
Интеграция с offlineimap
Я выбрал Python, потому что знал, что offlineimap может вызывать скрипты, написанные на Python. Если вы уже пользуетесь offlineimap, вы поймете, что единственная необходимая «интеграция» сводится к изменению двух строк в вашем файле .offlineimaprc (точнее — к добавлению одной строки и изменению другой).
Сначала добавьте строку, ссылающуюся на файл нашего скрипта:
Теперь вместо пароля в строке с remotepasseval после знака «=» вызовите функцию get_api_pass(), которая живёт в скрипте password_prompt.py:
Всё! Теперь никто не сможет прочитать пароль из вашего конфигурационного файла!
Безопасность даёт свободу
Иногда кажется, что у меня паранойя: я много думаю о тонкостях обеспечения безопасности на моём личном компьютере. Действительно ли SSH конфиг должен иметь разрешения chmod 600? Действительно ли имеет значение, что пароль электронной почты находится в конфигурационном файле, спрятанном в скрытой папке, которая называется, как ни странно, .mutt? Хотя написать подобный скрипт на Python можно и для других конфигурационных файлов.
Зная, что в моих файлах конфигурации отсутствуют незашифрованные конфиденциальные данные, мне намного проще публиковать файлы в общедоступных репозиториях Git, копировать и вставлять сниппеты на форумах и делиться своими знаниями в форме актуальных, рабочих файлов конфигурации. С этой точки зрения, повышение уровня безопасности облегчило мне жизнь. А с таким количеством Python-модулей на все случаи жизни, сделать это было достаточно легко.
Аренда облачного сервера с быстрыми NVMе-дисками и посуточной оплатой у хостинга Маклауд.
Прикреплённый файлы:
Crypto_test.zip (831 байт)
Шифрование пароля в файле конфигурации ini
VIRTOKПоставь пакет pycrypto (через pip3 ставится), там есть алгоритм AES для крепкого шифрования. Так шифруешь пароль, потом через модуль base64 кодируешь его в текстовый вид и сохраняешь в ini-файле. Для обратной процедуры читаешь зашифрованный пароль в формате base64, раскодируешь из base64, расшифровываешь из AES. Пароль для AES можешь хранить в программе или брать по сети.
пароль должен безопасно хранится в файле config.ini но из файла конфигурации программа должна его подхватывать не в зашифрованном виде
Шифрование пароля в файле конфигурации ini
Если не затруднит прошу привести пример кода
все что я на данный момент сообразил
Отредактировано VIRTOK (Окт. 10, 2018 17:50:29)
Шифрование пароля в файле конфигурации ini
> Пароль для AES можешь хранить в программе или брать по сети.
С дураками и сектантами не спорю, истину не ищу.Ели кому-то правда не нравится, то заранее извиняюсь.
Шифрование пароля в файле конфигурации ini
возможно нужно будет зашифровать хранящиеся пароли дргим паролем который не хранить в конфигурационном файле ?
Шифрование пароля в файле конфигурации ini
VIRTOK
Если не затруднит прошу привести пример кода
RodegastКошелёк с паролями в системе тоже легко прослушивается. Можно пароль хранить в конфиге, который закрыт на доступ. Программа может брать пароль из этого конфига через какой-нибудь механизм тонкого доступа к файлу.
Вот только такое хранение пароля мало чем отличается от хранения в открытом виде.
Шифрование пароля в файле конфигурации ini
Прошу комментировать строчки , принцип ясен , но есть пробелы
Шифрование пароля в файле конфигурации ini
Шифрование пароля в файле конфигурации ini
1.Мне надо защитить информацию от обывателя , что бы поле с паролем в конфиге не читалось
2. Желательно использовать главный пароль который будет расшифровывать остальные, я его буду вводить и тогда пароли из конфигов будут использоваться
3. Прошу привести пример кода если не вас не затруднит
Шифрование пароля в файле конфигурации ini
> Кошелёк с паролями в системе тоже легко прослушивается.
Ну это уже от системы зависит.
> Можно пароль хранить в конфиге, который закрыт на доступ. Программа может брать пароль из этого конфига через какой-нибудь механизм тонкого доступа к файлу.
Если злоумышленник получил доступ к конфигу с шифрованными паролями, то скорее всего он получит доступ и к самой программе. А достать от туда пароль или понять от куда он берёться не составляет труда.
Читайте также: