Когда вы вводите имя пользователя и пароль перед хостом, эти данные таким образом не отправляются на сервер. Вместо этого он преобразуется в заголовок запроса в зависимости от используемой схемы аутентификации. В большинстве случаев это будет Basic Auth , который я опишу ниже. Аналогичная (но значительно реже используемая) схема аутентификации - Digest Auth , которая в настоящее время обеспечивает сопоставимые функции безопасности.
При базовой аутентификации HTTP-запрос из вопроса будет выглядеть примерно так:
GET / HTTP/1.1
Host: example.com
Authorization: Basic Zm9vOnBhc3N3b3Jk
Строка, похожая на хеш, которую вы видите там, создается браузером так: base64_encode(username + ":" + password).
Для посторонних лиц при передаче HTTPS эта информация скрыта (как и все остальное на уровне HTTP). Вы должны позаботиться о регистрации на клиенте и всех промежуточных серверах. Имя пользователя обычно будет отображаться в журналах сервера, а пароль - нет. Это не гарантируется, хотя. Когда вы вызываете этот URL на клиенте, например, с помощью curl, имя пользователя и пароль будут четко видны в списке процессов и могут появиться в файле истории bash.
Когда вы используете подход с помощью ayush , имя пользователя и пароль будут всегда появляться в журналах сервера вашего веб-сервера, сервера приложений, кешей, ... если вы не настроили специально ваши серверы, чтобы не войти. Это относится только к серверам, которые могут считывать незашифрованные данные http, например к вашему серверу приложений.
Базовая аутентификация стандартизирована и реализована браузерами с помощью этого небольшого всплывающего имени пользователя / пароля. Когда вы вводите имя пользователя / пароль в форму HTML, отправляемую через GET или POST, вы должны самостоятельно реализовать всю логику входа / выхода из системы (что может быть преимуществом). Но вы должны никогда передавать имена пользователей и пароли по параметрам GET. Если вам нужно, используйте вместо этого POST. По умолчанию предотвращает запись этих данных.
При реализации механизма аутентификации с формой ввода имени пользователя / пароля и последующим сеансом на основе файлов cookie, как это обычно используется сегодня, необходимо убедиться, что пароль передается либо с помощью запросов POST, либо с помощью одной из стандартных схем аутентификации. только выше.
В заключение я могу сказать, что передача данных таким образом по HTTPS безопасна, если вы позаботитесь о том, чтобы пароль не появлялся в неожиданных местах. Но этот совет относится к любой передаче любого пароля любым способом.