Безопасное хранение паролей, когда доступ к открытому тексту все еще необходим

Возможный дубликат:
PHP 2-way encryption: мне нужно хранить пароли, которые можно получить

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

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

Я планирую AES_ENCRYPT пароли в БД, а это значит, что если кто-то может получить доступ к БД, они не смогут получить открытый текст. Однако моему коду нужно будет иметь доступ к ключу, чтобы их разграничить, поэтому, если весь сервер взломан, это не защита, и пароли будут обнаружены.

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

ИЗМЕНИТЬ

Я знаю, что независимо от того, что я делаю, в конечном счете пароли должны быть доступны в виде открытого текста, и поэтому скомпрометированный сервер означает, что пароли будут обнаружены, но мне интересно, какие шаги я могу предпринять для смягчения моего риска. НАПРИМЕР. шифрование БД защищает меня в ситуации, когда БД взломан, но не весь сервер. Другие аналогичные шаги по смягчению были бы очень оценены.

Ответ 1

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

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

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

Хранилище данных - храните пароли вдали от места, где может проникнуть злоумышленник. Доступ к контролируемым файлам с высоким доступом, база данных на задней машине и т.д. Сделайте, чтобы любой злоумышленник прошел через уровни защиты, чтобы добраться до места данные сохраняются. Аналогичным образом обеспечивается защита сети, например, брандмауэры и обновленные патчи безопасности. Здесь никто не работает изолированно.
Шифрование - любая технология шифрования - это тактика задержки - одна у злоумышленника есть ваши данные, они в конечном итоге взломают ваше шифрование с учетом бесконечного количества времени. Поэтому в основном вы пытаетесь замедлить их достаточно долго, чтобы остальная часть системы обнаружила, что вы были взломаны, предупредили своих пользователей и дали пользователям время на изменение паролей или отключение учетных записей. ИМО - либо симметричная, либо ассиметричная криптография будут работать - пока вы надежно храните ключ. Будучи самим PKI, я склоняюсь к асимметричному криптографии только потому, что я лучше понимаю его и знаю о некоторых аппаратных решениях COTS, которые позволяют надежно хранить мой секретный ключ.
Ключевое хранилище - ваше шифрование не хуже вашего хранилища ключей. Если ключ сидит рядом с зашифрованными данными, то разумно, что злоумышленнику не нужно нарушать криптографию, они просто используют ключ. HSM (аппаратные модули безопасности) - это лучший выбор для хранения ключей - в верхних диапазонах это безопасные блоки, которые являются защитой от несанкционированного доступа, которые удерживают ваши ключи и выполняют криптографию для вас. На нижнем конце токен USB или смарт-карта могут выполнять ту же функцию. Критической частью этого является то, что в конечном счете, лучше всего, если вы активируете ключ активации ключа при запуске сервера. В противном случае у вас будет сценарий с курицей и яйцом, когда вы попытаетесь выяснить, как безопасно хранить окончательный пароль.
Обнаружение вторжений - есть хорошая система на месте, которая имеет хорошие шансы поднятия тревог, если вы должны быть взломаны. Если ваши данные пароля скомпрометированы, вы хотите, чтобы слово для ваших пользователей значительно опережало любую угрозу.
Аудит регистрации - действительно хорошие записи о том, кто сделал то, что в системе - особенно в непосредственной близости от ваших паролей. Хотя вы можете создать довольно удивительную систему, угроза привилегированных пользователей, которые делают что-то плохое (или немое), так же плохо, как внешние угрозы. Типичные системы аудита высокого уровня отслеживают поведение пользователей с высокими привилегиями таким образом, что не могут быть просмотрены или изменены пользователем с высокими правами - вместо этого есть вторая учетная запись "аудитор", которая имеет дело только с журналами аудита и ничего больше.

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

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

Ответ 2

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

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