Я читал о Проверка подлинности Windows в IIS7
По опыту я знаю, что проверка подлинности Windows технически работает нормально через Интернет с использованием IIS - это означает, что пользователь сталкивается с проблемой 401 не авторизован, и что большинство браузеров (Chrome, FF, IE, Safari) запрашивают домен \ пользователь и пароль Windows, и что если аутентификация проходит успешно, и в случае авторизации пользователь получает запрошенную страницу.
Но потом я прочитал это:
Проверка подлинности Windows не подходит для использования в Интернет-среде, поскольку эта среда не требует и не шифрует учетные данные пользователя.
HTTPS можно использовать для шифрования, но мне нужны разъяснения по другой части.
Что означает "не требует учетных данных"?
И, исходя из этого, реальный вопрос: помимо использования HTTPS для шифрования, как мне безопасно реализовать аутентификацию Windows для использования в Интернет-среде?
Заявление Microsoft кажется необоснованным. Я понимаю, что при использовании NTLM вместо Kerberos вы теряете прямое соединение с доверенным сторонним поставщиком удостоверений, но это не объясняет мне, почему учетные данные не потребуются при правильной реализации. Ищу этот метод. Спасибо.
most of em don't use https either (even over internet) because they are too cheap to pay for certificates.
Настройка веб-сайта на требование Https обеспечит разумную меру безопасности. Если вы ищете что-то еще, потому что они не хотят использовать / платить за сертификаты, вы зря тратите время. Внедрение Windows Auth через Интернет без использования SSL было бы безответственным, поскольку встроенный механизм аутентификации Windows может не работать по разным причинам. Когда это происходит, им предлагается ввести учетные данные, которые передавались бы по сети в виде обычного текста, если бы SSL не требовался.
И мы даже не думали, нужно ли шифрование данных.
Кроме того, как NTLM, так и Kerberos отправляют полезные данные заголовка авторизации http с каждым пакетом, и этот заголовок включает хешированные / измененные учетные данные. Kerberos будет более безопасным, чем NTLM, но оба могут быть подвержены атаке с воспроизведением MITM, если SSL не используется.
По моему опыту, может быть сложно заставить Windows Auth надежно работать даже во внутренних сетях, а запрос учетных данных по незашифрованным HTTP-соединениям, когда он не работает, - это слабость, которую нельзя игнорировать. Существует множество сценариев, в которых это может не работать, в том числе слишком большой заголовок token / auth из-за членства в группах и / или недостаточных параметров конфигурации IIS, или учетные данные Windows не синхронизированы между клиентом и доменом Active Directory. Слишком большой размер токена возникает только с Kerberos, поскольку членство в группах хранится в Kerberos PAC.
Основная причина, по которой у вас не должно быть локальной аутентификации и доступа к интернет-сайту, заключается в том, что если ваш веб-сервер скомпрометирован, все ваши локальные учетные записи будут скомпрометированы. С помощью Kerberos вы можете обновлять пароли и централизованно контролировать аутентификацию.
Теперь для аутентификации Kerberos можно использовать вкладки SPN-ключей, и у вас есть разные типы шифрования. https://uit.stanford.edu/service/kerberos/keytabs в то время как NTLM только частично использует шифрование https://blogs.msdn.microsoft.com/chiranth/2013/09/20/ntlm-want-to-know-how-it-works/. Если NTLMSPP полностью не поддерживается и не обновляется в вашей ОС, вы будете отправлять учетные данные в виде обычного текста. http://www.cisco.com/c/en/us/support/docs/security/web-security-appliance/118487-technote-wsa-00.html и https://en.wikipedia.org/wiki/NTLMSSP. NTLM в настоящее время не расширяется и не является предпочтительным протоколом https://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx.
Как видите, в документации MS имя пользователя представлено в виде обычного текста, а пароль хеширован. Против NTLM возможны «легкие» атаки - передача хеш-кода или предсказание случайного числа, сгенерированного в сеансе, а затем получение из него пароля. Вдобавок к этому NTLM поддерживает шифрование 56 и 128, так что это ниже, чем у любого сравнительно недавнего метода.
Невозможно безопасно реализовать локальную аутентификацию для веб-службы. Пожалуйста, дайте мне знать, если это имеет смысл.