Что является недостатком безопасности в этом процессе аутентификации по незащищенному HTTP?

Первый вопрос здесь :)Что является недостатком безопасности в этом процессе аутентификации по незащищенному HTTP?

Я читал много вопросов о том, как защитить логин на сайтах без https. Все они очень интересны, и большинство ответов сводятся к «Использовать SSL, если вы заботитесь о безопасности!». Я согласен с этим, но я также задаюсь вопросом, какой недостаток в этой конкретной процедуре (один пользователь (= меня), без сеансов: пароль всегда отправляется с полным содержимым тега <html>, который заменяет текущий содержимое этого файла):.

сервер посылает две переменные на страницу: случайного маркера а и в = derivedfrom (A).
клиент отправляет обратно md5 (пароль + отметка времени + B) и A.
Сервер выводит B из A, чтобы выполнить тот же md5hash, что и клиент, и сопоставляет хэши сервера и клиента.
Сервер допускает не более 1 запроса в секунду на каждый IP-адрес.

Предполагая, что злоумышленник знает все допустимые пары А и В, есть ли способ для него/ее подлинности успешно, кроме атак воспроизведения (в течение 100мс периода времени, что хэш является действительным) и чистой случайности, что он догадывается правильный хеш для данного конкретного периода времени?

Конечно, злоумышленник все равно может попробовать все возможные пароли, но это не изменяется с помощью https.

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

Как вы введете свой путь, если на данный момент на сайте нет трафика?

источник

2017-02-02 Michael Paul

Есть несколько недостатков здесь:

Вы не должны использовать md5. Пожалуйста, используйте какой-либо другой алгоритм хеширования (например, sha256)
Чтобы сделать то, что вы говорите, серверу необходимо хранить пароли в виде открытого текста. Это очень плохая практика, как если бы вас взломали, все пароли будут скомпрометированы. Вместо этого вы должны сохранить засоленный хэш пароля. Дополнительная информация здесь: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
Этот метод является недопустимым, так как временная метка не может быть известна серверу, за исключением случаев, когда часы клиента и сервера синхронизированы с миллисекундой (не предполагайте, что они будут). Даже если часы полностью синхронизированы, это все равно не сработает. Время, с которого клиент берет временную метку до тех пор, пока пакет не достигнет сервера, не будет переменным, и серверу необходимо будет точно знать это время. Без правильной отметки времени сервер не сможет вычислить хеш. Удаление метки времени приведет к повторным атакам.
Злоумышленник, выполняющий атаку «человек в середине», может изменить код HTML (или что-то еще) на лету и удалить функцию хеширования (при условии, что это выполняется в JavaScript). Затем браузер передаст пароль. Конечно, аутентификация не удастся, но у злоумышленника будет пароль.
Возможно, существуют и другие недостатки, но этого достаточно, чтобы метод был неэффективным, я верю.

Итог: Не используйте HTTP для аутентификации пользователей.Я не слышал о каких-либо случаях безопасной проверки подлинности через HTTP. Если SSL очень дорог, вы можете использовать его только для страницы входа. Это по-прежнему очень плохая практика, так как злоумышленник может выполнить захват сеанса путем кражи сеансовых файлов cookie (и других атак типа «человек в середине»), но по крайней мере пароль не будет показан таким образом.

источник

2017-02-02 11:20:12 jackgu1988

Спасибо за ваш ответ. Просто для того, чтобы прояснить несколько моментов: на сервере есть только один пароль, открытый (мой). Если сервер захвачен, у меня есть более серьезная проблема, чем раздача моего пароля. Однако то, что вы говорите, очень важно для защиты паролей других людей, просто не относится к этому случаю только одного пользователя. Что касается отметки времени, она округляется до 100 мс (или до 10 мс, если это доказывает достаточно надежную). Как именно вы предполагаете, что HTML будет изменен в моем браузере? –

Однако, полагая, что часы клиента и сервера отлично синхронизированы, в 100 мс клиент должен вычислить хэш и отправить его на сервер по сети. Если ваше интернет-соединение не достаточно быстрое, это всегда будет терпеть неудачу. Изменение HTML, когда вы не используете SSL, очень просто при выполнении атаки MITM. Проверьте такие инструменты, как ettercap. Вот простой скрипт, например: https://www.irongeek.com/i.php?page=security/ettercapfilter Вместо изображения вы можете изменить любой контент HTML (скрипты и т. Д.). – jackgu1988

Если вас интересует более подробная информация о нападении MITM, пожалуйста, проверьте здесь: http://security.stackexchange.com/questions/72652/javascript-injection-using-man-in-the-middle-attack – jackgu1988

Что вы описали, это небольшая техническая деталь в более крупной процедуре, в которой вы вообще не заходите в детали. Я , предполагая, что большая цель этой процедуры - войти в систему? Тогда что происходит после обмена этим токеном? Получает ли пользователь какой-то постоянный токен, например, cookie? Тогда это восприимчивое к:

людям в середине атак чтения всех коммуникаций
пакета локальной сети нюхает, лихо освещался в Firesheep attack

Даже если (это большого, если) эта конкретная схема токена была безупречной, вся цепочка связи наблюдалась третьими сторонами, и все личные данные (включая идентификационные файлы cookie) можно было читать в яслях неавторизованными пользователями в привилегированной сети pos (→ session hijacking).

источник

2017-02-02 11:58:42 deceze

Процедура в моем случае: пользователь редактирует html-страницу (с помощью ), а затем отправляет тэг html через ajax в php-скрипт, который проверяет соответствие пароля и если это так, заменяет файл, который запрашивает пришли из. Как я уже говорил, сеанса нет. Коммуникация нечувствительна, так как она обновляется только на общедоступной странице. Также нет куки-файлов, поэтому я не вижу, как применяется атака Firesheep. –

OK, Firesheep не применяется тогда. Но человек-в-средстве все еще очень подходит; злоумышленник в привилегированной сетевой позиции может переписать ваш запрос и изменить любой контент, который вы пытаетесь загрузить (скорее всего, добавить к нему вредоносные скрипты и т. д.). – deceze

Что является недостатком безопасности в этом процессе аутентификации по незащищенному HTTP?

ответ

Смежные вопросы