Плохая идея передавать имя пользователя и пароль в URL при использовании SSL?

Question

Сценарий:

У меня есть веб-сайт ASP.Net / Silverlight с веб-сервисами для поддержки приложений Silverlight с данными. Веб-сайт использует проверку подлинности с помощью форм, поэтому веб-службы также могут проверять подлинность запросов.

Теперь я хотел бы вытащить некоторые данные из этой системы в приложение для Android. Я мог бы реализовать код для запуска формы входа в систему и сохранения файла cookie аутентификации, но на самом деле было бы гораздо проще отправить имя пользователя и пароль в URL-адресе веб-службы и аутентифицировать каждый вызов. Я не вижу большой проблемы с этим, так как общение зашифровано с помощью SSL, но я открыт, чтобы быть уверенным в обратном;)

Что ты думаешь? Плохая идея / не очень плохая идея?

Вывод:

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

Решение:

Я отправлю имя пользователя и пароль с запросом. Минимальная дополнительная работа и более безопасный.

Answer 1

См. Безопасны ли параметры строки запроса в HTTPS (HTTP + SSL)?

Все будет зашифровано, но URL-адреса, а также строка запроса (и, следовательно, пароли) будут отображаться в файлах журнала сервера.

Answer 2

Плохая идея : содержимое вашего сообщения зашифровано, и хотя параметры URL-адреса также могут быть зашифрованы, они все равно могут быть видны сторонним трекерам, журналам сервера или некоторому другому программному обеспечению для мониторинга, которое может напрямую нюхать ваш трафик. Это не очень хорошая идея, чтобы открыть потенциальную дыру в безопасности таким образом.

Answer 3

Пользователи, как правило, копируют и вставляют URL-адреса прямо из своей адресной строки в электронные письма, блоги и т. Д., Сохраняют их в закладках и т. Д.

И такие вещи, как плагины или даже другое программное обеспечение, которое читает, например, свойства окна (альтернативные оболочки, менеджеры тем, программное обеспечение для специальных возможностей), могут заканчиваться информацией. И они могут, например, аварийно завершить работу и автоматически отослать данные о сбоях своим разработчикам.

И черви, гораздо менее изощренные, чем келоггеры, - например, такие вещи, которые требуют screendumps - могут получить пароли таким образом. Иногда даже программное обеспечение безопасности, например, если развернуто в корпоративной сети.

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

И по этим и другим причинам URL-адреса с именами пользователей и паролями, которые раньше были стандартными - например, FTP-URL с именами пользователей и паролями в сегменте полномочий - теперь обычно запрещаются браузерами.

http://tools.ietf.org/html/rfc3986#section-7.5

Итак, решительное НЕТ, НЕ ДЕЛАЙТЕ ЭТОГО.

Answer 4

Это всегда хорошая практика программирования, чтобы не предоставлять деликатную информацию, такую ​​как имя пользователя и пароль в URL. Независимо от того, насколько хорош сайт, он может быть скомпрометирован. Так зачем предоставлять больше информации?