Как хранить пароль AD в корпоративном web-приложении?
Суть в следующем: имеется корпоративный портал (web) с доменной (AD) аутентификацией. В для входа в портал, пользователь вводил доменную учетку и пароль. Чтобы не вводить постоянно логин/пароль они запоминаются в куках браузера. В службе информационной безопасности сказали, что хранить пароль AD в куках не есть гуд, я с ними полностью согласен.
Собственно вопрос, а как тогда безопасно хранить пароль? Или тупо сохранять сессию на, скажем, две недели, а потом опять спрашивать пароль?
P.S. Должно работать во всех браузера.
Корпоративный но есть зоопарк браузеров т.к. Используются разные системы и всем им подавай свой браузер с настройками... Если бы был только скажем IE вопросов бы не было, NTLM решило бы проблему.
Самый быстрый и простой вариант - также хранить логин, а вместо пароля хэш пароля из БД, ведь там храните не в открытом виде? Если узнают даже хэш из БД, то узнать пароль сложно будет. Если сеть слушают, то и ключ сессии также можно спереть, надо все под https ставить.
Роман Сопов: получается в БД в открытом виде храните? Тогда в куки пишите md5('пароль' + соль) , допустим. При авторизации по логину ищете юзера, его пароль (из БД) опять в хэш и сравниваете что в куках, если совпало, то текущий пароль (из БД) отдаете AD. Если используете сессию или планируете в будущем, то можно через сессию.
Arik: тоже вариант, но СБ он опять-таки не понравился мол в БД пароли хранятся в открытом виде... Надо и пользователя запомнить, и пароль нигде в открытом виде не хранить, и авторизацию всегда делать в AD...
А чем собственно не устраивает хранение того же SHA-хеша пароля в кукис?
Шифрование одностороннее. Взломать его как бы невозможно.
Также установите expiration time на сессию, по истечении времени производите снова запрос в AD и обновляйте куки.
Так нужно делать не только в Вашем случае, так делают практически во всех случаях работы с внешним ААА сервером.
Для того чтобы снизить количество запросов к серверу и соответственно нагрузку на последний прибегают к механизму кеширования авторизации. После удачной первой авторизации через внешний сервер, обычно создают запись в локальном репозитории. В случае с браузером, как у вас, это обычно делается через куки. У меня, к примеру, написанный на Джаве клиент, поэтому я сохраняю имя пользователя и хеш пароля в базе данных. Теперь для того, чтобы обеспечить дополнительный уровень безопасности, добавляем параметр "время жизни авторизации", например 2 часа, в течении которых все действия пользователя, требующие авторизации, проходят через локальный кеш. По истечении 2 часов, следушее действие будет авторизовано снова через внешний сервер и в случае успешного прохождения Вы продлеваете сессию в локальном кеше. Если же авторизация провалилась, то соответственно удаляете запись.
NetBear: ну положили мы хэш пароля в базу, как я потом аутентифицирую пользователя по истечении сессии БЕЗ его нехэшированного пароля? Ему придется его вводить, верно? Верно. Аутентификация исключительно по AD, а ему скормить хэш пароля не получится....
Роман Сопов: По истечении сессии Вы аутентицируете пользователя посредством внешнего сервера -- AD в вашем случае. Параллельно с отправкой *пароля* в запросе к серверу, Вы считаете его хеш. Ок? Теперь, если ответ на запрос вернулся положительный, то открываете двухчасовую сессию и кешируете *хеш пароля*, если же отрицательный, то сессию не открываете и ничего в кеш соответственно не сохраняете.
Простой
Средний
