Хранение паролей для аутентификации в другой системе

Это не обычный вопрос: «Безопасно ли хранить пароли пользователей обычного текста?». Нет, это небезопасно, мы все это знаем.Хранение паролей для аутентификации в другой системе

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

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

«Тупым» решением является сохранение имени пользователя/пароля в текстовом виде и использование его для аутентификации, но, очевидно, это небезопасно. Пароли могут быть зашифрованы, но что, если кто-то ворвется в систему?

Возможное решение: использовать DPAPI для шифрования/дешифрования пароля (и, возможно, даже имени пользователя) прозрачно. Это хорошая идея? Это безопасно? Как насчет настроек с несколькими компьютерами (совместимо ли шифрование между машинами)?

Есть ли у вас дополнительные предложения?

источник

2009-11-03 Dario Solera

Я думаю, что DPAPI вероятно, ваша лучшая возможность. Я не понимаю, что вы имеете в виду в отношении веб-ферм, хотя ... –

Я не уверен, что это именно то, что вы ищете, но как насчет решения хэширования, такого как DBM и такое использование? Хешируйте пароль пользователя для хранения, и когда они аутентифицируются, хешируют пароль, который они предоставляют, и сравнивают его с существующим хэшем. Это обычно используемый способ хранения паролей. P.S. - В зависимости от уровня безопасности, который вы хотите/нуждаетесь, я бы рекомендовал солить ваши хэши, чтобы избежать атак типа радужного стола. См. Последнюю версию статьи «2600» для статьи о том, как Microsoft долго хранит пароли пользователей с несоленными хэшами. –

@Bob: не то, что было задано! Ему нужен пароль, потому что он отправляет его во внешнюю систему. Он аутентифицируется против кого-то другого, не аутентифицируется в его системе. –

DPAPI обычно не может использоваться в веб-фермах - хранилище ключей относится к машине. Вы не указали, используют ли определенные пользователи один набор учетных данных, а другой пользователь использует другой набор учетных данных. Если все пользователи используют один и тот же набор учетных данных, сохраните его в файле web.config и сделайте с ним. Защитите учетные данные, используя либо API шифрования конфигурации, либо простые ACL в файле web.config.

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

источник

2009-11-03 07:00:12 Chris

Скрипт для дополнительных пользователей должен обязательно знать учетные данные. – Will

Проблема с шифрованием с помощью хэша паролей пользователя (плюс соль) заключается в том, что добавлять новые пользователи сложно после настройки, потому что вам нужен пароль другого пользователя (например, администратор, добавляющий пользователей). Кроме того, если пользователь меняет свой пароль, вам необходимо повторно зашифровать ее «копию» учетных данных внешней системы. Это может быть жизнеспособным решением, хотя и немного запутанным. –

@ Dario Я не уверен, что понимаю сложность. Учитывая ОП, я предположил, что пользователь предоставил учетные данные третьей стороны после настройки своей первоначальной учетной записи (или ее доступа в первый раз). Учитывая, что пароль пользователя уже будет доступен в хэш-форме в этот момент, было бы тривиально шифровать любые учетные данные, предоставленные пользователем, используя указанный хэш + соль. Да, вам придется повторно шифровать учетные данные каждый раз, когда пользователь изменяет свой главный пароль, но это вряд ли кажется необычным требованием. – Chris

Помните, что клавиши DPAPI находятся на уровне пользователя. Если вы не собираетесь настраивать и хранить отдельную копию учетных данных, установленных для каждого пользователя, DPAPI не принесет вам никакой пользы. Единственный надежный способ сделать это будет с моделью «надежной подсистемы», в которой у вас есть служба Windows, работающая как некоторый пользователь, с защищенными данными, хранящимися в улей HKCU этого пользователя, зашифрованными с помощью ключа DPAPI. Он выполняет все действия в системе, требующей аутентификации от имени пользователя, а имя пользователя/пароль не загружается в процесс пользователя. Даже при этом, если пользователь является администратором, они могут технически по-прежнему получать имя пользователя/пароль, отлаживая процесс обслуживания.

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

источник

2009-11-03 07:01:59 nitzmahone

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

Однако, скорее всего, ваша операционная система (например, Windows) предлагает способы обеспечения безопасности файлов и, вероятно, что они реализованы опытными специалистами - сложно рекомендовать инвестировать время в прокат самостоятельно!

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

Зашифрованные домашние каталоги, где ваш веб-сервер работает в качестве своего собственного потребителя, так как только она может получить на своих данных
целом шифрования диска

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

Сам вопрос распространяется на отказ от ответственности, поэтому этот вопрос не нуждается в трудностях.

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

источник

2009-11-03 07:13:54 Will

Хранение паролей для аутентификации в другой системе

ответ

Смежные вопросы