Аутентификация домена Google Chrome и пароли открытого текста в заголовке HTTP

В ответе на « Аутентификация Windows с помощью Google Chrome» указано, что Chrome еще не поддерживает автоматическую аутентификацию NTLM, что означает, что пользователям, проходящим аутентификацию на сайтах с использованием аутентификации Windows, предлагается ввести логин. Что раздражает, но не проблема. Проблема заключается в том, что пароль пользователя затем отправляется в виде открытого текста на сайт аутентификации.

Я создал быстрый скрипт ASP.NET, который извлекает пароль из AUTH_PASSWORD в коллекции Request.ServerVariables. И Safari, и Opera запрашивают учетные данные пользователя, но ни один из них не отправляет пароль в виде открытого текста в заголовке HTTP. Я нахожу это особенно странным, поскольку Chrome, как Safari, основан на WebKit.

В чем разница между способом аутентификации Chrome по сравнению с другими браузерами и почему он отправляет пароль на сайт таким образом?

NTLM в настоящее время переносится на Chrome. Смотрите это . Просто дождитесь следующей версии.

Одна из возможностей заключается в том, что Chrome может вообще не поддерживать NTLM, и Chrome просто возвращается к аутентификации HTTP BASIC . Можете ли вы получить точные заголовки, используемые с wireshark или аналогичным?

В ответ на ваш комментарий к ответу bdonlan:

Я предполагаю, что не смогу увидеть аутентификацию, потому что сайт, на котором я работаю, использует SSL.

Инструмент Burp Proxy позволяет просматривать (и даже изменять) HTTP-запросы и ответы, а также может выступать в качестве HTTPS-прокси. (Это может работать или не работать в зависимости от того, как Chrome использует HTTPS-прокси.)

Из того, что я могу сказать через Wireshark, Chrome поддерживает NTLM-аутентификацию. Он не поддерживает единую регистрацию, передавая существующие учетные данные.

Вот почему поле AUTH_PASSWORD пустое.