Безопасно/правильно ли передавать логин и пароль в заголовке по HTTPS протоколу?

Question

[Heretic Man]

Пример запроса:
curl -H "username: user" -H "password:12345" https://mysite.com

Еще волнует вопрос можно ли прослушивая трафик перехватить эти заголовки.
Хотелось бы получить развернутый ответ про не безопасность данного подхода.

Про OAUTH и токены знаю.

Comments

[Vitsliputsli]

https для того и сделан, чтобы шифровать передаваемые данные. Опасность - подделка сертификата.
Но в вашем варианте, я бы больше опасался того, что вы пароль прописали прямо в строку, которая сохранится, например в истории bash и будет фигурировать в списке выполняемых команд.

Answer 1

[Владимир Дубровин]

Никогда не городите самопальной криптографии и методов авторизации, если вы не криптограф и не appsec-специалист соответственно, используйте стандартные подходы и проверенные библиотеки. В вашем случае надо использовать HTTP basic-авторизацию и стандартные механизмы которые ее реализуют.

Comments

[FanatPHP]

а чем васик-то лучше этого? ))))

[Владимир Дубровин]

тем что для basic есть стандартные механизмы и библиотеки, и для клиента и для сервера, например его скриптом не получишь и в логах на сервере он наверняка не осядет

Answer 2

[Vitaly Karasik]

Ответ - да, правильно. Все вебсервисы это делают - Google, FB, и 99% остальных.
Это неидеально, поэтому стараются дополнить MFA (дополнительный разовый пароль) или сертификатом, но в целом ничего более надежного и легкоиспользуемого нет.

Answer 3

[Алекс]

Если Коротко: Безопасно и это пока стандартный подход. Да перехватить пароль можно, и в зависимости от браузера, пользователь не узнает что его SSL/TLS "читает" что-то по середине.

Если Развернуто , то сейчас уже в моде использовать другой подход - на стороне браузера, при помощи JScript/Subtle crypt генерировать хеш/PBKDF от пароля и передать на сервер. Сервер в свою ичередь тоже должен генерировать с этого значения, вторичный хеш и уже его можно хранить\ искать в БД для аутентификации пользователя. А первичный хеш не в коем не хранить на сервере! но его можно использовать для других целей, например де-шифрования данных для 2ФА метода.
И раз уже твой фронт будет использовать JScript/Subtle crypt, то это открывает допольнительные возможности сквозного шифрование более широкого набора данных пользователя в режиме сквозного шифрования.

посмотри как сделан сервис mega.nz. у них опен сорс.