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

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

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

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

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

Решение

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

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

3 4
password-protection

3 ответа:

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

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

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

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

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

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

5

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

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

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

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

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

1

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

Плюсы:

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

Минусы:

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