Как управлять паролями в конфигурации приложения

Question

Я работаю над системой, которая взаимодействует со многими внешними системными API: s. Большинство из них требуют аутентификации. Для удобства использования есть приложение AppConfig с широким охватом приложений, которое хранит информацию о конфигурации, а также учетные данные для внешних систем.

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

Чтобы получить доступ к файлу конфигурации, вам необходимо либо поставить под угрозу файловую систему сервера, либо репозиторий git на другом сервере (или, конечно, в любой системе разработчика). Я думал, что шифрование пароля в файле конфигурации не повышает уровень безопасности, так как ключ шифрования должен быть где-то сохранен. Неужели я ошибаюсь?

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

Решение

Итак, вот мое окончательное решение. Я создал простую библиотеку, использующую OpenSSL для шифрования и дешифрования моих конфиденциальных данных. Ключ извлекается у пользователя при загрузке конфигурации, за исключением производственных серверов, где он хранится в файле. Это все еще не оптимальное решение, но оно лучше, чем «решение», которое я ранее имел.

Благодарим за ответы. Я соглашусь с ответом Уэйна, поскольку он был самым информативным.

Answer 1

Хорошая безопасность.

Как говорит Брюс Шнайер: «Безопасность - это компромисс». Вы должны решить, насколько безопасно вы хотите эту информацию, и сколько времени вы хотите потратить на обеспечение указанной информации. И вы определенно не хотите оставлять пароли просто сидеть там в виде обычного текста, это не-нет. Если вы находитесь в ситуации, когда все в порядке, вы находитесь в ситуации, когда вы не должны иметь аутентификацию пользователя.

Несмотря на то, что безопасность сложна, есть несколько вещей, которые вы можете сделать.

1) Используйте некоторый тип скомпилированной программы для шифрования/дешифрования. Вы не хотите, чтобы кто-то открыл скрипт Python/perl и сказал: «Ага, это просто шифрование XYZ», хотя в идеале вы не хотите простого шифрования.

2) Безопасность через неясность - это не настоящая безопасность, но она может помочь против случайного слежения. Например, именование файла «passwords.txt» не является ужасно хорошей идеей, но лучше шифрование ваших паролей, а затем использование стеганографии, чтобы скрыть пользователя/пропуск в каком-то файле изображения.

3) Найдите надежные алгоритмы шифрования/дешифрования. Некоторые из них уже реализованы на большинстве языков, и вы можете просто импортировать библиотеку. Это может быть плохо или хорошо, в зависимости от того, насколько безопасно вы думаете, что хотите этого.

Но, честно говоря, эта система действительно плохая - разумная защита. В идеале у вас есть двухсторонняя аутентификация, а затем доверенный посредник делает все колесо и дело. Например, когда вы входите в систему на своем компьютере, вы говорите компьютеру, что являетесь авторизованным пользователем. Оттуда вы можете запускать все свои программы, и они не спрашивают или не заботятся о вашей комбинации пользователей и пропусков - просто вы являетесь авторизованным пользователем. Они получают эту информацию от ОС (средний человек). Черт, даже SO использует openID, чтобы решить, что вы доверенный пользователь - им все равно, какие ваши учетные данные находятся на других сайтах, только то, что другие сайты говорят «Да, это действительный пользователь."

Если у вас есть возможность, я бы серьезно рассмотреть вопрос о переходе модель аутентификации. Если нет, то удачи.

Answer 2

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

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

Я рекомендую использовать 1024-битное шифрование, есть a couple good algorhytms. Я также рекомендую использовать бит 64/128 random salt для каждой записи, которую вы шифруете, так что даже если пароль для одной записи принудительно принудительно, решение не будет работать на другие записи. Random Salting предотвращает атаки Rainbow table, что заставляет ваш крекер использовать грубую силу, гораздо больше времени.

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

Edit:An example of how the salt makes encryption more secure, even if the encryption key is known.

Answer 3

Некоторые webbservers необходимо загрузить симметрично шифрованные сертификаты на старте. Чтобы справиться с этим, они запрашивают ввод пароля при запуске. Так что он сохраняется только в памяти.

Плюсы:

• Мастер-пароль никогда не хранится на диске.
• Главный пароль не может быть извлечен из ps fax.

Минусы:

• Мастер пароль еще может быть извлечен дампа памяти (от пользователя, запустившего webbserver и корень).
• Ваш процесс не может быть автоматически перезагружен без вмешательства пользователя. Вероятно, это самая большая причина, по которой не так много людей с этим вариантом. К счастью, веб-серверы редко сбой.