Каков наилучший способ сохранить настраиваемые пароли, не делая их слишком легко доступными для обычного читателя?

Question

У меня есть база данных, к которой подключаются различные клиентские приложения (небольшая сеть веб-служб, некоторые Java-приложения и несколько сетевых приложений). Не все из них работают на окнах (к сожалению, в противном случае это облегчило бы ответ с простым включением аутентификации Windows для соединений с базой данных). На данный момент пароли хранятся в различных файлах конфигурации / свойств, лежащих вокруг систем. В идеале, только сотрудники службы поддержки имеют доступ к серверам, на которых запущены файлы, но если кто-то еще получит доступ к одному из серверов, у него будет достаточно разрешений для базы данных, чтобы получить достаточный объем данных в том виде, в котором они сейчас находятся.

Тогда мой вопрос: каков наилучший способ сохранить настраиваемые пароли, не делая их слишком легко доступными для обычного читателя-человека?

Редактировать Просто уточнить, что сервером БД является Windows Server 2003, на котором выполняется MSSQL 2005.

PS: Я не вижу вопросов, которые повторяются, но если они есть, пожалуйста, не стесняйтесь закрывать этот.

Answer 1

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

Помните, что вам не нужно использовать одну и ту же защиту для каждого отдельного клиента. Несколько шагов: -

1. Создание разных учетных записей базы данных для разных систем, которые обращаются к вашей базе данных
2. Ограничить доступ к базе данных только тем, что им нужно, используя встроенную базу данных GRANTs
3. Храните тройной ключ DES (или любой другой) внутри класса менеджера паролей в вашей базе данных. Используйте это, чтобы расшифровать зашифрованное значение в вашем файле свойств.

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

Answer 2

Давайте предположим следующий общий сценарий:

• Вы используете одну и ту же базу кода для всех сред, и ваша база кода имеет пароли базы данных для каждой среды.

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

• Вы не хотите, чтобы кто-либо, имеющий доступ к исходному коду, знал, что такое рабочие пароли.

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

Если вы используете Java, посмотрите на this для более конкретного примера. В примере используются Spring и Jasypt. Я уверен, что что-то подобное можно экстраполировать на другие среды, например .Net

Answer 3

На моем старом рабочем месте у нас была система, в которой все пароли были зашифрованы (с использованием Triple DES или того, что мы использовали в то время). Пароли часто хранились в файлах свойств (это было в системе Java).

Когда пароль нужно было изменить, мы могли бы просто использовать «! Plaintext» в качестве значения, а затем наш код загрузил бы его, зашифровал и сохранил зашифрованное значение обратно в файле свойств.

Это означало, что можно было сменить пароль, не зная, каково было первоначальное значение - не уверен, что это то, о чем вы просили!

Answer 4

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

Если это так, вот что вы можете сделать:

1) Измените любые клиентские приложения, которые подключаются напрямую к БД, для прохождения через службу. (Если у них есть для прямого подключения, то, по крайней мере, дайте им первый шаг к «получению пароля» от службы, тогда они могут подключиться напрямую).

2) Сохраните пароли в файле web.config (если вы решили использовать веб-службы .Net), а затем зашифруйте раздел файла «строки подключения».

Answer 5

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

Answer 6

Да, я должен согласиться с вариантом хранения (соленых) хэшей. Я бы порекомендовал (соленый) хэш SHA256 пароля, хранящегося в базе данных. Также не забудьте применить правила безопасного пароля.

Answer 7

Использование шифрования не очень хорошая идея. Если кто-то скомпрометирует ключ, он сможет его расшифровать. Используйте алгоритм хеширования с солью для хранения паролей. Алгоритмы хеширования являются одним из способов, поэтому он необратим. Но они уязвимы для атак по словарю, поэтому используйте соль (простой текст с чем-то длинным и многословным, чем хэш) Он также защищает базу данных от внутренних атак.

Answer 8

Аутентификация NTLM или аутентификация на основе LDAP (Active Directory) должна быть доступна вам с небольшим усилием. Это позволит вам использовать «проверку подлинности Windows» в разных приложениях.

Это может означать небольшую миграцию для вашего оперативного персонала, но SSO для набора приложений - это хорошо.

Answer 9

Что касается java, если вы используете сервер приложений, посмотрите, можете ли вы определить источник данных, и ваши приложения могут получить доступ к источнику данных с помощью JNDI. Таким образом, управление источником данных (включая сведения о соединении) обрабатывается сервером приложений, и код вашего приложения должен запрашивать источник данных.

Answer 10

Вы можете использовать алгоритм обратимого шифрования, например, Blowfish для хранения паролей в качестве временной меры. Должно быть несколько бесплатных библиотек, которые вы можете использовать, чтобы встроить их во все ваши программы, которым необходим такой доступ.

Страница Брюса Шнайера на Рыба-рыба

Статья в Википедии Рыба-Окунь