Как управлять паролями в настройках приложения

Question

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

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

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

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

Решение

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

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

Answer 1

Хорошая безопасность - это сложно.

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

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

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

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

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

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

Answer 2

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

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

Я рекомендуюпри использовании 1024-битного шифрования есть пара хороших алгоритмов .Я также рекомендую использовать 64/128 бит случайная соль для каждой записи, которую вы шифруете, чтобы даже если пароль для одной записи был взломан, решение не будет работать с другими записями.Случайное засоление предотвращает атаки с помощью таблиц Rainbow, что заставляет вашего взломщика использовать грубую силу, намного больше времени.

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

Редактировать: Пример того, как соль делает шифрование более безопасным, даже если известен ключ шифрования.

Answer 3

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

Плюсы:

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

Минусы:

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