Безопасны ли обратимо зашифрованные пароли, и почему они не работают, когда включены для пользователя?
В моем журнале событий, когда мой маршрутизатор пытается использовать Radius для аутентификации, я получаю следующее:
"" "Пользователь не может пройти проверку подлинности с помощью протокола проверки подлинности при вызове (CHAP). Для этой учетной записи не существует обратимо зашифрованного пароля. Чтобы убедиться, что обратимо зашифрованные пароли включены, проверьте политику паролей домена или настройки пароля на учетная запись пользователя. """
Тем не менее, я включил это для учетной записи, которую я использую в свойствах пользователя в AD. Есть ли какое-то другое место, где это нужно включить, или, может быть, мне нужно подождать, пока оно реплицирует или перезапустить службу (кроме Radius)? Сервер IAS - это тот же компьютер, что и контроллер домена, и я внес изменения на этом компьютере, поэтому я думаю, что они вступят в силу немедленно.
Кроме того, насколько небезопасно "обратимо зашифрованные пароли"?
Редактировать:
Я должен также вероятно сказать, почему я делаю это, если есть лучший способ. Я настраиваю маршрутизатор Cisco на конечную точку для инициируемых клиентом туннелей L2TP/IPSec. Я хочу пройти аутентификацию с помощью AD, поэтому, если есть лучший способ обработки аутентификации, пожалуйста, дайте мне знать:-) В идеале, я все равно мог бы использовать встроенный клиент Windows VPN.
3 ответа
Почему это не работает, очевидно, потому что пароль должен быть сброшен. Я смог сделать это через Active Directory.
Кроме того, кажется, я могу настроить маршрутизатор и сервер Radius для использования ms-chap-v2, для которого не требуется, чтобы я хранил пароли с обратимым шифрованием.
Ссылка на mh точна: если что-то хранится таким образом, что его можно восстановить, это следует рассматривать не лучше, чем открытый текст. Поскольку это реализовано в AD, включение обратимого шифрования означает, что любой (или что-либо) с правами администратора домена может дешифровать пароли, потому что у них есть доступ к глобальному секрету LSA, который является единственной частью процесса, которая является секретной в любом смысле, все остальное может быть прочитано кем-либо из AD или содержится в DLL, которой можно манипулировать \ осуществлять обратный инжиниринг.
С точки зрения атаки, если у кого-то есть права администратора домена, игра уже закончена, но с точки зрения внутренней безопасности это также означает, что администраторы домена могут дешифровать пароли в исходный текст, что не годится. Если бы не что иное, я бы не хотел участвовать в расследовании безопасности, где ключевым доказательством были записи в журнале событий, показывающие, как пользователь входит и выходит из системы с помощью пароля, который я технически мог бы знать, если бы захотел.
Здесь есть интересный набор записей в блоге Нильса Теусинка на эту тему.
Существует много лучших альтернатив с точки зрения аутентификации (сертификаты X.509, токены одноразовых паролей, смарт-карты...), но возможность их использования зависит от вашего приложения и клиентской системы, которую должны использовать пользователи. Если у вас есть полный контроль над средой, вы сможете найти решение, которое позволит вам избегать их использования, но их правильная реализация может быть дорогостоящей, а ваши пользователи могут счесть их неудобными.
Отредактированный после вашего обновления, я бы предложил использовать встроенные сертификаты AD, это будет немного трудоемко, но конечный результат будет солидным, и вы сможете повторно использовать эту возможность для множества других вещей.
Страница Microsoft TechNet на этом ( здесь) в основном говорит:
"Хранение паролей с использованием обратимого шифрования по существу аналогично хранению незашифрованных версий паролей. По этой причине эту политику никогда не следует включать, если требования приложений не перевешивают необходимость защиты информации о паролях".