Каковы векторы атаки для паролей, отправляемых через http?

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

Насколько я понимаю, на любом из переходов по пути можно использовать анализатор пакетов для просмотра того, что отправляется. Похоже, что для этого требуется, чтобы любой хакер (или его вредоносная программа / ботнет) находился в той же подсети, что и любой из прыжков, которые требуется пакету для достижения пункта назначения. Это правильно?

Предполагая, что некоторая разновидность этого требования подсети верна, мне нужно беспокоиться обо всех переходах или только о первом? Первое, о чем я, очевидно, могу беспокоиться, если они находятся в общедоступной сети Wi-Fi, поскольку кто-то может их прослушивать. Должен ли я беспокоиться о том, что происходит в подсетях, через которые пакеты будут проходить за пределами этого? Я не знаю тонны о сетевом трафике, но я бы предположил, что он проходит через центры обработки данных основных операторов, и там не так много сочных векторов атак, но, пожалуйста, исправьте меня, если я ошибаюсь.

Есть ли другие векторы, о которых нужно беспокоиться, если кто-то слушает анализатор пакетов?

Я новичок в области сетей и безопасности, поэтому, пожалуйста, не стесняйтесь, если вы используете неправильную терминологию в любом из этих случаев.

Обратите внимание на то, что другие здесь не упоминали, что некоторые браузеры кешируют данные вашей формы. Поведение по умолчанию на сайтах SSL обычно не кэширует ничего, если вы не выбрали «сохранить мой пароль». Обычно поля пароля не кэшируются в любом случае, но я видел некоторые странности (обычно информация о кредитной карте, которая, как я знаю, на самом деле не является темой вопроса).

Следует также отметить, что шифрование SSL начинается при установлении связи TCP. Однажды в SSL вы не можете отличить HTTP через SSL от FTP через SSL (кроме предположений, сделанных через номер порта).

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

В целом, если вы исключите атаки «человек посередине» из спектра, вы сократите множество потенциальных атак, но это не означает, что ваш сайт «безопасен». Кроме того, политика зонирования должна помочь защитить вас от атак XSS, поскольку вы будете вносить изменения в зону, если ваш пользователь перенаправлен с вашего сайта.

Данные уязвимы в любом месте маршрута, а не только на первом или последнем этапе. Вполне возможно, что система, участвующая в передаче, ищет имена пользователей, пароли и другие конфиденциальные данные. Отсюда следует, что конфиденциальные данные должны передаваться только по защищенной ссылке, и, конечно же, именно для этого нужен SSL. В зависимости от того, какие данные задействованы, вполне могут быть местные законы, предписывающие SSL.

Есть прокси-серверы, которые могут хранить данные.

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

Ваш анализ обоснован, ИМХО.

Надо отметить, что на вашем пути могут быть кеши. Таким образом, может случиться так, что запрос будет где-то зарегистрирован (особенно если логин закончен через GET, что было бы ужасно).

Вероятно, следует учитывать, что большая часть доступа к сети происходит в области, где в той же сети находится много других людей. Работа / Uni / Школа - главные примеры. Дома вы можете утверждать, что это менее рискованно, потому что вам нужно беспокоиться только о пути вверх.

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

Но давайте будем реалистичны. Почти наверняка этот вектор атаки не способ, которым его система или пользователи будут скомпрометированы.

НТН.

Я могу согласиться с размышлениями КевинаМ о том, чтобы отвечать на его собственные вопросы, и Джон Гарденье указывает в правильном направлении. Я также должен согласиться с тем, что сказал Шелковистый: «в идеале - широкая публика никогда не будет заходить на сайт, на котором нет экрана входа в систему на основе SSL», и указать, однако, что это не современный случай. совсем.

Я не согласен с шелковистым тоном (возможно, непреднамеренным), который ведет к повсеместному восприятию, что «широкая публика» глупа. Клиент KevinM явно не имеет понятия о необходимости SSL, и это ваш средний человек в двух словах. Они не глупы, они просто не знают. Сказать «тебе нужно это» будет нелегальный ответ: «Я прожил х лет без него, и я проживу х больше, просто отлично», или, возможно, даже худший ответ «Я ненавижу, когда мне говорят, что мне нужно «. Так что будь осторожен!

Ваше беспокойство законно, Кевин. Вашему клиенту нужен сертификат SSL. Я думаю, что ваша настоящая забота должна заключаться в том, как продать их один. Обеспокоены не только логины пользователя, но и логины администратора и оператора, которые также выиграют от защиты по SSL.

Да, в этом отношении нужно беспокоиться и о других вещах, даже больше, чем обнюхивание пакетов, таких как XSS . Они многочисленны и хорошо документированы .

во всем маршруте, сопровождаемом пакетом, если можно перехватить его через HTTP и увидеть данные ... даже если вы используете HTTP в Proxy, таком как TOR ... с использованием сбора урожая и т. д. можно обмануть Прокси для утечки пакетов данных ... поэтому, если есть что-то близкое к чувствительным (пароли, личные данные, личные изображения и т. д.) ... целесообразно передавать их только по HTTPS.

Это также, даже HTTPS уязвим с неправильной реализацией, и их можно применить к нескольким SSL-атакам ... тем не менее, их можно избежать с осторожной реализацией.

Но использование HTTP для обычного текста похоже на приглашение даже новичков н / ж детей понюхать пароли.