Имя пользователя и пароль в https url

Ответ 1

Когда вы ставите имя пользователя и пароль перед хостом, эти данные не отправляются на сервер. Вместо этого он преобразуется в заголовок запроса в зависимости от используемой схемы аутентификации. В большинстве случаев это будет Basic Auth, о котором я расскажу ниже. Аналогичная (но значительно менее часто используемая) схема аутентификации - это Digest Auth, которая в настоящее время обеспечивает сопоставимые функции безопасности.

С Basic Auth запрос HTTP из вопроса будет выглядеть примерно так:

GET / HTTP/1.1
Host: example.com
Authorization: Basic Zm9vOnBhc3N3b3Jk

Хэш, например, строка, которую вы видите, создается браузером следующим образом: base64_encode(username + ":" + password).

Для аутсайдеров передачи HTTPS эта информация скрыта (как и все остальные на уровне HTTP). Вы должны позаботиться о регистрации на клиенте и на всех промежуточных серверах. Имя пользователя будет обычно отображаться в журналах сервера, но пароль не будет. Однако это не гарантировано. Когда вы вызываете этот URL на клиенте, например, curl, имя пользователя и пароль будут хорошо видны в списке процессов и могут появиться в файле истории bash.

Когда вы используете подход ayush, имя пользователя и пароль всегда будут отображаться в журналах сервера вашего веб-сервера, сервера приложений, кэшей... если вы специально не настроили серверы, чтобы не регистрировать его. Это относится только к серверам, которые могут читать незашифрованные http-данные, например, ваш сервер приложений.

Базовый auth стандартизирован и реализован браузерами, показывая это маленькое всплывающее имя пользователя/пароля. Когда вы вводите имя пользователя/пароль в форму HTML, отправленную через GET или POST, вы должны сами реализовать логику входа/выхода (что может быть преимуществом). Но вы никогда не должны передавать имена пользователей и пароли по параметрам GET. Если вам нужно, используйте POST. Это предотвращает регистрацию этих данных по умолчанию.

При внедрении механизма аутентификации с формой ввода пользователя/пароля и последующим сеансом на основе файлов cookie, как это обычно используется сегодня, вы должны убедиться, что пароль либо транспортируется с помощью запросов POST, либо только одна из стандартизованных схем аутентификации выше.

В заключение я мог бы сказать, что передача данных по HTTPS безопасна, если вы заботитесь о том, что пароль не появляется в неожиданных местах. Но этот совет относится к любой передаче любого пароля каким-либо образом.