Действительно ли обратимо Зашифрованные пароли безопасны, и Почему это не работа при включении для пользователя?
Вы просите монитор целостности файлов (FIM), но так как Вам интересно только на файлах с Вашего веб-сайта, можно, вероятно, сделать это удаленно.
1 - Для FIM локально на поле, я предложил бы OSSEC. Это работает исходно в Windows и позволяет централизованную конфигурацию (при необходимости в этом).
2 - Для FIM удаленно (или Основанный на сети Контроль Целостности), я предложил бы NBIM, который в свободном доступе в: http://sucuri.net (отмечают, что я - разработчик этого инструмента, поэтому возьмите мое мнение с мелкой частицей соли).
Наилучший вариант, я верю, был бы удаленный FIM, так как возможности его поставленный под угрозу меньше, чем база данных внутренней целостности, и он также обнаруживает внешние нарушения (как кто-то изменяющий записи DNS для перенаправления сайта где-то в другом месте).
То, почему это не работало, было, по-видимому, потому что пароль должен быть изменен. Я смог сделать это через Active Directory.
Кроме того, кажется, что я могу настроить маршрутизатор и сервер Радиуса для использования ms-chap-v2, который не требует, чтобы я снабдил пароли обратимым шифрованием.
Страница TechNet Microsoft на этом (здесь) в основном говорит:
"Хранение паролей с помощью обратимого шифрования является по существу тем же как хранящий версии простого текста паролей. Поэтому эта политика никогда не должна включаться, если требования к приложению не перевешивают потребность защитить информацию о пароле".
-
1
ссылка mh является пятном на - после того как что-то хранится способом, что это может быть восстановлено, это, должен быть рассмотрен не лучше, чем простой текст. Поскольку это реализовано в AD, разрешающем обратимые средства шифрования, что любой (или что-либо) с правами Администратора домена может дешифровать пароли, потому что у них есть доступ к глобальному секрету LSA, который является единственной частью процесса, который используется, который секретный в любом смысле, все остальное включенное может быть считано из AD любым или содержится в DLL, который может быть спроектированным manipulated\reverse.
С точки зрения нападения, если кто-то имеет права Администратора домена, это уже игра закончена, но с точки зрения внутренней безопасности это также означает, что Администраторы домена могут дешифровать пароли в исходный простой текст, который не хорош. Если ничто иное, я не хотел бы сталкиваться с расследованием безопасности, где ключевое доказательство было записями журнала событий, показывающими пользователю, входящему в систему и использующему пароль, который технически я мог знать, хотел ли я.
Существует интересный набор записей в блоге Niels Teusink на предмете, запускающемся здесь.
Существует много лучших альтернатив с точки зрения аутентификации (Сертификаты X.509, Маркеры Одноразового пароля, Смарт-карты..), но можете ли Вы использовать их или не зависите от Вашего приложения и клиентской системы, которую должны использовать пользователи. Если Вы имеете полный контроль над средой, необходимо смочь найти решение, которое позволяет Вам избегать использования их, но реализация их правильно может быть дорогостоящей, и Ваши пользователи могут найти их неудобными.
Отредактированный после Вашего обновления я предложил бы использовать AD Интегрированные Сертификаты, это будет немного работы, но конечный результат тверд, и можно снова использовать возможность большого количества других вещей.