Вход без HTTPS, как обезопасить?

Question

Для веб-приложения, когда HTTPS недоступен в качестве меры безопасности, возможно ли по-прежнему сделать вход в систему несколько безопасным? E.g.:

• Маркировать логины, чтобы затруднить повторные атаки?
• Как-то зашифровать отправленный пароль из поля пароля HTML?

В частности, я использую CakePHP и вызов AJAX POST для запуска аутентификации (включая предоставленные имя пользователя и пароль).

Обновление по проблеме:

• HTTPS недоступен. Период. Если вам не нравится ситуация, считайте это теоретическим вопросом.
• Нет явных требований, у вас есть все, что HTTP, PHP и браузер (куки, JavaScript и т. Д.) Предлагает в реальной жизни (без волшебных бинарных файлов RSA, плагинов PGP).
• Вопрос в том, что лучше всего сделать из этой ситуации, которая лучше, чем отправка открытого текста паролей. Знание недостатков каждого такого решения является плюсом.
• Любые улучшения лучше простых паролей приветствуются. Мы не стремимся к 100% l33tG0Dhx0r-proff решению. Сложнее взломать лучше, чем сложнее взломать, что лучше, чем обычное прослушивание, раскрывающее пароль.

Answer 1

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

Если ваш хост не поддерживает HTTPS, то такая служба, как Cloudflare Universal SSL , может использоваться для обеспечения подключения всех браузеров к вашему сайту с использованием HTTPS, , даже если ваш сервер не поддерживает SSL / TLS . Соединение между Cloudflare и вашим сайтом по-прежнему будет незащищенным, но эта служба Cloudflare предназначена для защиты пользователей от угроз, обнаруженных в общественных сетях Wi-Fi. С точки зрения тестера на проникновение, весьма подозрительно не предоставлять HTTPS, если вы не предоставляете базовое требование безопасности как доставку трафика, то какие еще требования безопасности вы пропускаете? Сертификаты HTTPS можно получить бесплатно, используя Let's Encrypt или Запустите SSL , нет законных оснований не поддерживать HTTPS.

HTTPS жизненно важен, потому что он делает гораздо больше, чем просто «шифрует пароли». Еще одна важная роль заключается в том, что он не должен позволять пользователю входить на вредоносный сервер, который выдает себя за настоящий сервер. Использование системы для защиты одного пароля по-прежнему является нарушением OWASP A9 - Недостаточная защита транспортного уровня , поскольку вы все равно будете передавать учетные данные сеанса в виде простого текста, который является всем необходимым для атакующего ( Firesheep ).

1. Криптография на основе JavaScript не может использоваться для создания безопасного транспортного уровня .

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

3. «Как-то зашифровать переданный пароль»: после того, как человек вошел в систему злоумышленник может прослушать трафик, чтобы получить действительный идентификатор сеанса (cookie), а затем просто используйте это вместо входа в систему. Если весь сеанс был защищен с помощью SSL / TLS, тогда это не проблема.

Существуют и другие более сложные атаки, которые влияют как на эту систему, так и на нашу текущую инфраструктуру SSL. Атака SSLStrip становится более детальной. Я настоятельно рекомендую посмотреть выступление Мокси Марлинспайка о Blackhat 2009 , которое ведет к стандарту HTTP-Strict-Transport-Security .

Answer 2

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

В частности, я бы предложил вам использовать бесплатную стороннюю службу аутентификации, такую ​​как OpenID . У них есть библиотеки для PHP , включая одну для CakePHP .

---

Редактировать: (о рисках)

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

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

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

Если вы не можете использовать HTTPS для шифрования токена сеанса во время передачи на сервер и с него, вы не можете полностью предотвратить активные атаки, такие как перехват сеанса или человек-посредник атака. Это может быть приемлемым в некоторых случаях, например, на сайтах с небольшой базой пользователей для некоммерческого использования.

Answer 3

Короткий ответ таков: без шифрования SSL от конечной точки к конечной точке невозможно сделать это безопасно ...

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

Кроме того, вы никак не можете быть уверены, что источником учетных данных действительно является тот, с кем вы разговариваете. Это означает, что без SSL абсолютно невозможно быть уверенным в том, что атака «человек посередине» не происходит.

Так нет, ты не можешь этого сделать.

Кроме того, даже не пытайтесь. Получить SSL. Вы можете получить бесплатные сертификаты. Хозяева обычно дают вам выделенный IP за несколько долларов в месяц. И если вы действительно заботитесь о безопасности, вы все равно будете использовать хотя бы виртуальную машину с выделенным IP-адресом.

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

Answer 4

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

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

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

Answer 5

Вы можете использовать HTTP Digest аутентификацию, которая поддерживается большинством браузеров и не передает пароль в открытом виде по проводам.

Недостатком является уродливое окно входа в систему, отображаемое broswer. Если вы предпочитаете придерживаться форм, то вы можете реализовать точно такой же протокол, что и дайджест HTTP, в своей аутентификации форм: отправлять скрытые поля, содержащие область и вызов, а клиенту добавлять в JavaScript одноразовый номер и вычислять дайджест. Таким образом, вы будете использовать хорошо известный и проверенный протокол обмена, а не использовать свой собственный.

Дайджест HTTP требует только хеш-операций.

Answer 6

Вы можете зашифровать пароль с помощью Javascript и расшифровать его на сервере.

Я бы порекомендовал создать пару ключей RSA на сервере, отправить открытый ключ вместе с временной солью в браузер, а затем зашифровать пароль вместе с солью, используя открытый ключ в Javascript.

Вы можете найти реализацию RSA в Javascript здесь

Вы должны включить как IP-адрес, так и весь X-FORWARDED-FOR hedaer в куки аутентификации, чтобы предотвратить кражу куки за прокси.

Если вы имеете дело с конфиденциальными данными, вы можете сгенерировать случайный ключ AES в Javascript , а затем отправить его на сервер вместе с паролем, зашифрованным с помощью RSA.
Затем вы могли бы заставить все приложение использовать зашифрованные запросы AJAX с одной страницы и вообще не использовать файл cookie авторизации.

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

Answer 7

HTTPS имеет множество вариантов использования, большинство из которых предназначены для защиты от атак "человек посередине". Любой, у кого хакерское мышление, содрогнется и скажет вам, что нет другого способа, кроме устоявшегося способа чего-то достичь. Дело в том, что то, что вы используете TLS (стандарт, который использует современный HTTPS), не означает, что вы используете его хорошо. Кроме того, простое использование TLS не мешает кому-либо использовать известные недостатки. Точно так же, как вы находите творческие способы защиты ваших данных, есть люди, которые находят творческие способы использовать ваши меры безопасности.

Итак, что делать?

Прежде всего, если вы собираетесь отказаться от TLS, полезно понять, как это работает. И все дело в рукопожатии.

Как только клиент и сервер согласились использовать TLS, они договариваются о подключение с сохранением состояния с помощью процедуры квитирования. [7] Во время этого рукопожатие, клиент и сервер согласовывают различные параметры, используемые для установить безопасность соединения:

• Рукопожатие начинается, когда клиент подключается к серверу с поддержкой TLS. запрашивает безопасное соединение и представляет список поддерживаемых шифров сюиты (шифры и хеш-функции).
• Из этого списка сервер выбирает шифр и хэш-функция, которую он также поддерживает и уведомляет клиент решения.
• Сервер отправляет обратно свою идентификацию в форма цифрового сертификата. [противоречие] Сертификат обычно содержит имя сервера, доверенный центр сертификации (CA) и открытый ключ шифрования сервера.
• Клиент может связаться сервер, выдавший сертификат (доверенный CA, как указано выше) и Подтвердите действительность сертификата, прежде чем продолжить.
• Для того, чтобы генерировать сеансовые ключи, используемые для безопасного соединения клиента шифрует случайное число с помощью открытого ключа сервера и отправляет результат на сервер. Только сервер должен быть в состоянии расшифровать его, со своим закрытым ключом.
• Из случайного числа обе стороны генерируют ключевой материал для шифрования и дешифрования. [противоречие] Это завершает рукопожатие и начинает защищенное соединение, которое зашифрованы и расшифрованы с ключом материала до подключения закрывается.

Если какой-либо из вышеперечисленных шагов завершится неудачно, произойдет сбой квитирования TLS и соединение не создано.

Источник: Википедия

Так, это возможно? Да. Меня учили, что все возможно. Это может быть дорого, но всегда возможно.

Я хочу полностью раскрыть, что я НЕ специалист по безопасности, а просто энтузиаст. Я не рекомендую пытаться сделать это для проекта промышленного уровня или чего-то другого, кроме вашего собственного назидания. Вы должны ОПРЕДЕЛЕННО проверить эту публикацию SO , которая дает отличное объяснение препятствий при настройке собственного протокола безопасности.

Однако, если вы хотите двигаться дальше, вот некоторые мысли, которые приходят на ум. Это реальность, которая будет существовать независимо от того, какой прямой вы пошли с этим проектом.

• HTTPS поддерживается всеми основными современными браузерами. Даже с этой реальностью время загрузки HTTPS медленнее, чем обычный HTTP. Без большого объема производства весьма вероятно, что ваша альтернативная реализация будет настолько же безопасной, но значительно медленнее. Это будет недостатком любой домашней реализации, если только вы не используете функции браузера, что возвращает нас к использованию TLS, что и используется современным HTTPS.

• Если вам удастся зашифровать свой пароль без TLS на стороне браузера, используя Javascript достаточно непредсказуемым образом, что атака MiTM будет затруднена, не останавливайтесь на достигнутом. Вы также должны защищать данные, которые вы отправляете туда и обратно. В противном случае зашифрованный пароль действительно не имеет значения. Конечно, злоумышленник может не знать пароль пользователя bobsmith109, но он ему не нужен, потому что он может прослушивать каждое действие в сети. Он знает, сколько раз bobsmith109 входит в систему, вероятно, может отследить его IP-адрес и любые другие конфиденциальные данные, которые вы отправляете туда и обратно.

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

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

Было бы упущением не упоминать в своем посте, что с большинством реальных барьеров на пути использования HTTPS активно борются. Одна из самых больших - стоимость - очень близка к тому, чтобы стать не проблема. Бесплатный центр сертификации будет выпущен во втором квартале 2015 года, и его поддержат несколько крупных производителей, в том числе Mozilla и Akamai. Вот статья .

Answer 8

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

Конечно, это не мешает хакерам изменить сообщение ... но оно защищает ваш пароль.

Answer 9

Вход без HTTPS, как обезопасить?

Поскольку между вашим сервером и клиентом нет безопасного канала:

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

Что вы можете сделать? Theorically

• и клиент, и сервер должны использовать шифрование, чтобы сделать отслеживание / MITM менее восприимчивым.
• предположим, что вы не можете иметь рукопожатие,
• предположим, что у вашего клиента уже есть ваш ключ, и он знает, как говорить на том же языке, что и ваш сервер.
• как насчет SSL через HTTP, но для некоторых излишних слов обернутый в сообщение в кодировке base64?

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

-

Answer 10

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

Это не что-то безопасное, даже для установки искушенного злоумышленника недостаточно просто установить SSL, вам нужно использовать HSTS, закрепление открытого ключа и т. Д., Чтобы просто считать сайт безопасным сегодня .

Остальная часть ответа - просто пища для размышлений.

1. Создать пару открытый-закрытый ключ. Хранить в тайне.
2. Создайте файл js, содержащий открытый ключ и функцию encrypt, найдите алгоритм безопасного шифрования. Эта функция должна шифровать данную строку (сериализованную форму) с помощью дополнительной отметки времени, чтобы избежать атаки репликации.
3. Служите этому файлу с Cache-Control:public, max-age=31536000 заголовком HTTP. Мы пытаемся смягчить, когда злоумышленник пытается заменить сценарий. Файл всегда будет обслуживаться из кэша браузера.
4. Отправьте все формы через Javascript, используя функцию encrypt. Подайте их с тем же заголовком, что и выше.
5. На стороне сервера, decrypt данных, проверьте временную метку, если она все еще действительна. Делаете ли вы вещи, если нет, откажитесь от них.
6. Создайте маркер cookie, который можно использовать только один раз за очень короткое время. Если злоумышленник захватит печенье, у него не будет много времени, чтобы что-то сделать. Однако, если злоумышленник достаточно быстр, он может выйти из системы исходного пользователя.
7. Меняйте куки с каждым ответом. Но что вы делаете, когда пользователь отправляет несколько запросов одновременно, а затем они приходят в обратном порядке? Какой файл cookie действителен? Это создает массу проблем ценой ложного чувства безопасности.

Любые слушатели не смогут использовать данные, идущие туда-сюда, и они не смогут изменять / вставлять существующие JS файлы до истечения срока действия кэша / user очищает кеш Однако любой искушенный злоумышленник может заменить весь файл HTML, который отбросит все измерения безопасности, которые я только что упомянул. Если вы хотя бы сможете обработать этот файл / форму в течение HTTPS, вы могли бы сойти с рук, поместить их на страницы github или что-то еще. Однако, если вы поместите файл в другой домен, вам нужно настроить CORS для принимающего домена, чтобы это работало.

Еще одна попытка

Одноразовые пароли, отправленные на электронную почту.

1. Пользователь заполняет свою электронную почту, щелкает ссылку, которая затем отправляет ссылку на его электронную почту с токеном, который позволит им войти в систему.
2. Пользователь нажимает на ссылку
3. Сервер проверяет токен, регистрирует пользователя.
4. Закатывает куки, как в предыдущем примере.

В общем, что бы вы ни делали, это небезопасно . Учитывая быстрый, изощренный атакующий, ничто не мешает.

Получите SSL, если инфраструктура его не поддерживает, измените его. Если ваш менеджер не верит в SSL, убедите его / ее. Не создавайте ложное чувство безопасности. Защита данных вашего пользователя, в зависимости от вашего местоположения, вы по закону обязаны защищать данные своих пользователей.

Тогда давайте поговорим о том, как сделать сайт безопасным с помощью SSL.