Для веб-приложения, когда HTTPS недоступен в качестве меры безопасности, можно ли сделать логин несколько безопасным? Например:
В частности, я использую CakePHP и AJAX POST для запуска проверки подлинности (включая предоставленное имя пользователя и пароль).
Обновление проблемы:
HTTPS абсолютно необходим для поддержания безопасного соединения между веб-сайтом и браузером. Общественные сети Wi-Fi ставят пользователей под угрозу , а при правильном использовании HTTPS – единственный инструмент, который может защитить учетные записи пользователей от этой уязвимости .
Если ваш хост не поддерживает HTTPS, то служба, такая как Cloudflare Universal SSL, может использоваться для обеспечения того, чтобы все браузеры подключались к вашему сайту с помощью HTTPS, даже если ваш сервер не поддерживает SSL / TLS . Соединение Cloudflare с вашим сайтом будет по-прежнему незащищенным, но этот сервис Cloudflare предназначен для защиты пользователей от угроз, обнаруженных в общедоступных сетях Wi-Fi. С точки зрения тестера проникновения, не предоставляя HTTPS, очень подозрительно, если вы не предоставляете базовое требование безопасности для доставки трафика, то какие другие требования безопасности вы не видите? Сертификаты HTTPS можно получить бесплатно, используя «Зашифровать» или « Запустить SSL» , нет законной причины не поддерживать HTTPS.
HTTPS жизненно важна, потому что это намного больше, чем просто «шифрование паролей». Другая важная роль заключается в том, что он должен помешать пользователю входить во вредоносный сервер, который олицетворяет реальный сервер. Использование системы для защиты только пароля по-прежнему является нарушением OWASP A9 – Недостаточная защита транспортного уровня, потому что вы все равно будете передавать учетные данные сеанса в виде простого текста, который является всем потребностям злоумышленника ( Firesheep ).
Криптография на основе JavaScript не может использоваться для создания безопасного транспортного уровня .
«Tokenize logins»: если злоумышленник обнюхивает трафик, у него будет просто имя пользователя / пароль в текстовом формате, а затем они могут просто войти в систему с этими новыми учетными данными. (Повторная атака)
«Как-то зашифровать переданный пароль»: после того, как человек вошел в систему, злоумышленник может обнюхать трафик, чтобы получить действительный идентификатор сеанса (cookie), а затем просто использовать его вместо входа в систему. Если весь сеанс был защищен SSL / TLS, тогда это не проблема.
Существуют и другие более сложные атаки, которые влияют как на эту систему, так и на существующую инфраструктуру SSL. Атака SSLStrip идет более подробно. Я настоятельно рекомендую посмотреть рассказ Mochie Marlinspike Blackhat 2009 , который приведет к стандарту HTTP-Strict-Transport-Security .
Поскольку вы не можете выполнять SSL на веб-сервере, и вы не являетесь экспертом по безопасности, найдите существующую службу безопасной проверки подлинности, которую вы можете использовать, и позвольте им обрабатывать как SSL, так и сложность обработки учетных данных для вас.
В частности, я бы предложил использовать бесплатную стороннюю службу аутентификации, такую как OpenID . У них есть библиотеки для PHP, в том числе для CakePHP .
Изменить: (о рисках)
При использовании сторонней службы защищенной аутентификации (которая использует сам HTTPS) может устранить проблему, выполняющую само аутентификацию без использования HTTPS (на вашем сервере), она не полностью исключает возможность атак.
Наиболее распространенными двумя атаками будут атаки с повторением и захват сеанса, когда злоумышленник может повторно использовать подлинный токен входа в систему позже или использовать действительный токен сеанса для своей собственной злонамеренной цели.
Атака повторного воспроизведения может быть уменьшена с истечением срока действия токена сеанса и, предпочтительно, с помощью nonce для предотвращения повторения сеанса и снижения риска захвата сеанса. С помощью nonce легитимный сеанс генерирует ошибку, если успешно удалена, потому что значение nonce истекло (используется), поэтому их собственный сеанс больше недействителен.
Если вы не можете использовать HTTPS для шифрования токена сеанса во время его передачи на ваш сервер и с вашего сервера, вы не можете полностью предотвратить активные атаки, такие как захват сеанса или атака « человек-в-середине» . В некоторых случаях это может быть приемлемым, например, сайты с небольшой пользовательской базой для некоммерческого использования.
Короткий ответ заключается в том, что без использования конечной точки SSL до конечного шифрования невозможно сделать это безопасно …
Одной из основных причин этого является то, что вы не можете защитить крипто в браузере. См. Эту ссылку. Криптография Javascript считается вредной .
Кроме того, вы не можете быть уверены, что источник учетных данных действительно является тем, с кем вы разговариваете. Это означает, что без SSL абсолютно невозможно, чтобы быть уверенным в том, что не происходит Man-In-The-Middle Attack .
Так что нет, вы не можете этого сделать.
Кроме того, даже не пытайтесь. Получите SSL. Вы можете получить бесплатные сертификаты. Хосты обычно предоставляют вам выделенный IP-адрес за несколько $$$ в месяц. И если вы действительно заботитесь о безопасности, вы все равно будете использовать по крайней мере виртуальную машину с выделенным IP-адресом.
Чтобы даже попытаться, в лучшем случае это была бы безопасность через Obscurity , и ничто в худшем случае. SSL – проблема. Почему бы не использовать это решение. Безопасность – это не то, о чем можно догадаться. Используйте правильные методы. Не пытайтесь изобретать свои собственные. Это не сработает …
Как вы предположили, вы можете создавать уникальный токен каждый раз, когда страница создается. Этот же токен должен быть отправлен обратно с данными формы и не может быть повторно использован. Вы также можете сохранить пароль в безопасности, используя JavaScript для хеширования, если вы можете полагаться на то, что оно включено вашими пользователями.
Однако эта схема все еще небезопасна. Злоумышленник все еще мог видеть все, проходящее через провод. Они могут перехватить токен и отправить ответ вам до того, как пользователь сделает это. Или они могут просто подождать, пока кто-то войдет в систему, украсть учетные данные этого человека (поскольку они отправляются по кабелю) и просто сделать свой собственный запрос на вход позже.
Bottom Line – вам нужно использовать HTTPS, чтобы гарантировать безопасность сайта.
Вы можете зашифровать пароль с помощью Javascript и расшифровать его на сервере.
Я бы рекомендовал создать пару ключей RSA на сервере, отправить открытый ключ вместе с назначенной солью в браузер, а затем зашифровать пароль в сочетании с солью, используя открытый ключ в Javascript.
Вы можете найти реализацию RSA в Javascript здесь
Вы должны включить как IP-адрес, так и весь X-FORWARDED-FOR hedaer в файлы cookie аутентификации, чтобы предотвратить кражу файлов cookie за прокси.
Если вы имеете дело с конфиденциальными данными, вы можете создать случайный ключ AES в Javascript , а затем отправить его на сервер вместе с паролем, зашифрованным с помощью RSA.
Затем вы можете заставить все приложение использовать зашифрованные AJAX-запросы с одной страницы и вообще не использовать файл cookie.
Обратите внимание, что невозможно защитить от активной атаки «человек-в-середине» без SSL. Активный злоумышленник может полностью заменить ваш сайт своим собственным прокси-сервером, и нет никакого способа защитить его. (Поскольку не может быть никакого известного кода)
Вы можете использовать HTTP-дайджест- аутентификацию, которая поддерживается большинством браузеров и не отправляет пароль в ящике по проводу.
Недостатком является уродливый лог-код, отображаемый броузером. Если вы предпочитаете придерживаться форм, тогда вы можете реализовать точно такой же протокол, как HTTP-дайджест, в своих формах authnetication: отправить скрытые поля, содержащие область и вызов, а также добавить клиент в JavaScript и выполнить вычисление дайджеста. Таким образом, вы будете использовать хорошо известный и проверенный протокол exhange, а не сворачивать свой собственный.
HTTP Digest требует только хэш-операций.
Как насчет аутентификации HTTP Digest ? Он обеспечивает безопасность MD5-хэшированием имени пользователя, пароля и nonce (между прочим) перед отправкой на сервер. MD5 не очень безопасен, но это хороший способ для простой защиты с помощью HTTP.
Конечно, это не мешает хакерам изменять сообщение … но оно защищает ваш пароль.
HTTPS имеет множество вариантов использования, большинство из которых предназначены для защиты от атак «Man-in-the-middle». Любой, у кого есть настроение хакера, содрогнется, чтобы сказать вам, что нет иного способа, кроме как установить что-то. Дело в том, что только потому, что вы используете TLS (стандарт, который использует современный HTTPS), не означает, что вы его хорошо используете. Кроме того, просто использование TLS не мешает кому-либо использовать известные недостатки. Так же, как вы можете найти творческие способы защиты ваших данных, есть люди, которые находят творческие способы использования ваших мер безопасности.
Так что делать?
Прежде всего, если вы собираетесь отказаться от TLS, полезно понять, как это работает. И все дело в рукопожатии.
Как только клиент и сервер согласились использовать TLS, они ведут переговоры о соединении с состоянием, используя процедуру подтверждения связи [7]. Во время этого рукопожатия клиент и сервер согласуют различные параметры, используемые для установления безопасности соединения:
- Рукопожатие начинается, когда клиент подключается к серверу с поддержкой TLS, запрашивая безопасное соединение, и представляет список поддерживаемых наборов шифров (шифров и хеш-функций).
- Из этого списка сервер выбирает функцию шифрования и хэша, которая также поддерживает и уведомляет клиента о решении.
- Сервер отклоняет идентификацию в виде цифрового сертификата. [Противоречие] Обычно сертификат содержит имя сервера, доверенный центр сертификации (CA) и общедоступный ключ шифрования сервера.
- Клиент может связаться с сервером, который выдал сертификат (доверенный ЦС, как указано выше), и подтвердить действительность сертификата перед продолжением.
- Чтобы сгенерировать ключи сеанса, используемые для безопасного соединения, клиент шифрует случайное число с открытым ключом сервера и отправляет результат на сервер. Только сервер должен иметь возможность расшифровать его с помощью своего закрытого ключа.
- Из случайного числа обе стороны генерируют ключевой материал для шифрования и дешифрования. [Противоречие] Это завершает рукопожатие и начинает защищенное соединение, которое зашифровывается и дешифруется с помощью ключевого материала до тех пор, пока соединение не закроется.
Если какой-либо из вышеперечисленных шагов не удался, сообщение TLS не выполняется, и соединение не создается.
Источник: Википедия
Так, возможно ли это? Да. Меня учили, что все возможно. Это может быть дорого, но это всегда возможно.
Я хочу полностью раскрыть, что я НЕ профессионал безопасности, просто энтузиаст. Я не рекомендую это делать для проекта производственного класса или чего-либо другого, кроме вашего собственного назидания. Вы должны ОПРЕДЕЛЕНЫ проверить эту публикацию, которая дает отличное объяснение, касающееся контрольно-пропускных пунктов при настройке собственного протокола безопасности.
Однако, если вы хотите двигаться дальше, вот некоторые мысли, которые приходят на ум. Это реалии, которые будут существовать независимо от того, с какой прямой вы отправились с этим проектом.
HTTPS поддерживается всеми основными современными браузерами. Даже с этой реальностью время загрузки HTTPS медленнее обычного HTTP. Без обширного производства, весьма вероятно, что ваша альтернативная реализация будет частью безопасной, будучи значительно медленнее. Это будет недостатком любой домашней реализации, если вы не используете функции браузера, что возвращает нас к использованию TLS, что и использует современный HTTPS.
Если вам удастся зашифровать свой пароль без TLS на стороне браузера, используя Javascript в непредсказуемом виде, что атака MiTM будет сложной, не отдыхайте там. Вы также должны защищать данные, отправляемые туда и обратно. В противном случае пароль, зашифрованный, действительно не имеет значения. Конечно, злоумышленник может не знать пароль bobsmith109, но он ему не нужен, потому что он может обнюхивать все действия в сети. Он знает, в какое время бобмит109 входит в систему, возможно, может проследить его IP-адрес и любую другую чувствительную часть данных, которую вы отправляете туда и обратно.
Независимо от того, какие меры безопасности вы принимаете, есть безопасность в глубину. Таким образом, одна вещь, которую вы можете сделать сразу с места в карьер, это убедиться, что вы шифруете свои данные в базе данных, а также требуете надежных паролей.
Я повторяю, что я не профессионал в области безопасности и решительно отвергаю это как нечто иное, чем насыщение вашего любопытства. Астрономически маловероятно, что вы можете создать жизнеспособную альтернативу TLS без необычайно большой группы профессионалов в области безопасности, которые в течение многих лет вносят свой вклад в проект, а не десятилетия, что может похвастаться SSL / TLS. Это, как говорится, хорошая отправная точка, если вы решите идти вперед, – это посмотреть вышеприведенную модель рукопожатия и посмотреть, как вы можете реализовать версию этого без TLS.
Я был бы несовместим с тем, чтобы не участвовать в моем посту, что с большинством реальных барьеров на пути использования HTTPS активно бороться. Одна из самых больших – стоимость – очень близка к тому, чтобы стать не выпускной. Бесплатный сертификат будет выходить 2Q 2015 поддерживается некоторыми крупными пушками, в том числе Mozilla и Akamai, чтобы назвать несколько. Вот статья .
Посмотрите «Протокол безопасного безопасного пароля» .
Вместо того, чтобы формулировать это сам, позвольте мне процитировать их веб-сайт:
Протокол Secure Remote Password обеспечивает безопасную удалённую аутентификацию коротких человеко-запоминающихся паролей и противодействует пассивным и активным сетевым атакам.
а также:
Протокол [The] сочетает в себе методы доказательств нулевого знания с асимметричными протоколами обмена ключами и предлагает значительно улучшенную производительность по сравнению с более сильными расширенными методами, которые противостоят атакам с украденным верификатором, таким как Augmented EKE или B-SPEKE.
Хотя Стэнфордский университет не предоставляет реализаций для самих PHP и JavaScript, они ссылаются на некоторые сторонние реализации.
Одна из этих ссылок приводит к «Clipperz» , который является онлайн-менеджером паролей. Он также доступен как издание сообщества на GitHub. Там они размещают свою «javascript-крипто-библиотеку» , которая реализует протокол и сам «менеджер паролей» , который содержит бэкэнды, написанные на PHP и Python.
Я не могу сказать, насколько сложно было бы извлечь соответствующие части кода, но, может быть, вы сможете повторно использовать их реализацию (это лицензировано в AGPL).
Редактировать 2014/10/24:
Статья Википедии о SRP перечисляет еще несколько реализаций. Релевантно для PHP / JS:
Вы можете попытаться воспроизвести его до некоторой степени, используя шифрование с открытым ключом (возможно, GPG) и использование кеширования браузера.
Это не что-то безопасное, даже просто установить SSL будет недостаточно для сложного злоумышленника, вам нужно использовать HSTS, пиннинг с открытым ключом и т. Д., Чтобы просто рассмотреть веб-сайт сегодня .
Остальная часть ответа – это просто пища для размышлений.
encrypt , найдите алгоритм безопасного шифрования. Эта функция должна зашифровать заданную строку (сериализованную форму) с дополнительной меткой времени, чтобы избежать атаки репликации. Cache-Control:public, max-age=31536000 HTTP-заголовка Cache-Control:public, max-age=31536000 . Мы пытаемся смягчить, когда злоумышленник пытается заменить скрипт. Файл всегда будет обслуживаться из кеша браузера. encrypt . Подавайте их с тем же заголовком, что и выше. decrypt данные, отметьте метку времени, если она все еще действительна. Вы что, если нет, отбросьте это. Любые слушатели не смогут использовать данные, идущие туда и обратно, и они не смогут изменять / вставлять существующие JS файлы до тех пор, пока кэш не истечет / пользователь не очистит кеш. Однако любой сложный злоумышленник может заменить весь HTML файл, который отменит все измерения безопасности, о которых я только что упомянул. Если вы можете хотя бы обслуживать этот файл / форму через HTTPS , вам это может уйти, поместить их на страницы github или что угодно. Однако, если вы поместите файл в какой-либо другой домен, вам необходимо настроить CORS для домена-получателя, чтобы это работало.
Одноразовые пароли, отправленные по электронной почте.
В целом, что бы вы ни делали, это не безопасно . Учитывая быстрый, сложный атакующий, ничего не мешает.
Получите SSL, если инфраструктура не поддерживает его, измените его. Если ваш менеджер не верит в SSL, убедите его / ее. Не создавайте ложное чувство безопасности. Защитите данные своего пользователя, в зависимости от вашего местоположения, вам юридически требуется защитить данные ваших пользователей.
Тогда давайте поговорим о том, как сделать сайт безопасным с помощью SSL.
Поскольку между вашим сервером и вашим клиентом нет безопасного канала:
Но подождите … Поскольку вы не сказали ни одного волшебного бинарного файла или плагина, даже не RSA, я не знаю, возможно ли это, за исключением (возможно, очень слабого) внутреннего шифрования.
–
Прежде чем пытаться ответить, я хотел бы упомянуть, что каждый другой ответ здесь касается HTTPS / STS. HTTPS – это битва, ожесточенная, надежная и, вероятно, лучшая ставка – я уверен, что вы устали ее слышать. Теперь я не эксперт по безопасности, но эта проблема – это то, о чем я подумал, и я действительно создал способ. Я никогда не использовал его, и я просил бы всех, как можно больше, выкалывать дыры. Он защищает только от атаки «человек-в-середине».
Идея заключается в том, чтобы достичь разделяемой секретной части без рукопожатия, даже если это означает, что она защищает другую службу, которая является безопасной (например, электронная почта, предполагая, что они используют что-то с TLS для ее чтения).
Выберите симметричный шифр, возможно, Rijndael.
Выберите алгоритм хэширования, мои SHA256 / 512.
Создайте большую соль, какую-то случайную часть данных, в идеале несколько мускулистую. Возможно, 512 байтов. Назовем его GSALT. (подумайте об этом как о переменной GSALT). Это будет глобальная соль. Вероятно, хороший файл конфигурационного файла.
В вашей базе данных пользовательские данные должны содержать поле имени пользователя, поле userhash, поле пароля, поле солей, поле ключа и поле Keyhash (плюс все, что вы хотите, я занимаюсь только соответствующими полями). Я объясню, что должно содержать каждое поле:
Тем не менее, это забавный мысленный эксперимент! Я надеюсь, что это поможет кому-то (особенно если это означает, что он подталкивает их к использованию HTTPS)
Лучшим решением, которое я видел для нескольких безопасных HTTP-соединений, является использование Javascript-реализации md5sum (или другого хэша), чтобы избежать передачи пароля в виде открытого текста. Вы можете создать обработчик onsubmit формы в Javascript, который заменяет поле пароля хешем исходного значения. Это добавляет скромную степень безопасности к незащищенному соединению, но полагается на работу Javascript в браузере для правильной работы.
Ответ короче, и если вы действительно имеете в виду безопасность, у вас всегда есть варианты, на разных уровнях бюрократии.
Безопасность Absolut не существует. Ошибка номер один всегда на стороне клиента, с троянами и клавиатурными шпионами . SSL не помогает.
1) Генераторы токенов : банки используют их, тогда используется метель. Это может быть устройство или приложение. Ну .. это дорого.
2) SMS-штырьки . интересное и доступное решение. Существует много хороших цен от trnasactional sms на рынке, и у каждого есть телефон, способный его получить.
3) Если вам нужно использовать HTTP, вы можете заставить стороннюю службу oauth, например, google или facebook . Это лучшее, что вы можете сделать без генератора токенов.
Наверное, вы заботитесь о безопасной передаче пароля на сервер? Мой ответ: не передавать пароли на сервер 🙂
Infact вы не можете передавать что-либо от браузера (пользователя) на сервер для аутентификации пользователя, так как злоумышленник, который следит за HTTP-трафиком, также сможет повторно передавать данные и проверять подлинность.
Предложение:
Очевидным решением было бы использовать одностороннюю одноразовую аутентификацию транзакции, исходящую от сервера; как номер транзакции, который можно использовать только один раз. В конце концов вам по-прежнему нужен защищенный канал, чтобы синхронизировать список номеров транзакций с пользователем.
Вы могли бы использовать что-то аутентификатор google , но вам нужен защищенный канал один раз для настройки параметров с обеих сторон. Если вы считаете, что письмо является безопасным, это будет способ пойти.
У меня такая же проблема на моей системе. Я предпринял шаги, чтобы попытаться повысить безопасность, не ставя под угрозу работу пользователя с запутанными механизмами. Я заметил, что подавляющее большинство пользователей вошли в систему с одного и того же компьютера, используя один и тот же браузер (но не обязательно один и тот же IP-адрес), или из нескольких браузеров (например, рабочий стол или мобильный). Я решил использовать это, чтобы определить шаблон.
1) Во время регистрации пользователи должны иметь надежные пароли (для предотвращения атак со словарями), вопрос безопасности / ответа и стандартную проверку электронной почты (в качестве доказательства реального человека)
2) Во время входа в систему, после 5 неудачных попыток входа в систему (не раньше), для предотвращения нападений грубой силы отображается значок.
3) Наконец, я создал хэш частей строки user-agent после успешного входа в систему, содержащего ОС пользователей, браузер (общие не версии) и язык, образуя своего рода вторичный пароль. Если хеш useragent существенно отличается при следующем входе в систему, пользователю предлагается ответить на секретный вопрос. Тогда, если это будет удовлетворительно удовлетворено, новая строка UA будет хеширована и добавлена в список «безопасных машин», так что их не попросят снова с этой машины. Это похоже на механизм, используемый системой игр Steam.
Это уже более года работает с около 700 пользователями, и у него есть дополнительное преимущество для предотвращения «совместного использования» – проблема, когда несколько пользователей используют одни и те же учетные данные для удобства!
Попробуйте следующее: при каждом запросе страницы входа отправьте по ней и отметке времени. При отправке на сервер отправьте следующие четыре детали:
Имя пользователя, nonce и временная метка в открытом тексте. Затем соедините вышеуказанное с разделителем (например: newline) и зашифруйте с использованием пароля пользователя в качестве шифрования в режиме шифрования с цепным блоком.
В конце сервера используйте имя пользователя для поиска пароля и проверки зашифрованной строки.
Поскольку пароль никогда не отправляется в явном виде, он защищен и отметка времени может использоваться, чтобы избежать повторной отправки одних и тех же данных.
Чтобы избежать захвата сеанса путем получения ключа сеанса с помощью атаки «человек в середине», пароль или хэш пароля могут быть сохранены в памяти приложением на стороне клиента и использоваться для генерации уникальных ключей сеанса для проверки сервером.
Взгляд на OAuth 1.0 также неплохая идея.
Если вы не можете использовать HTTPS или вы не хотите использовать HTTPS, рассмотрите возможность использования jCryption . jCryption предлагает шифрование для данных, отправляемых по HTTP-запросам (POST, GET и т. д.).
Вы можете протестировать эту технику здесь: http://www.jcryption.org/#examples
Если вы используете Firebug, вы увидите, что все данные зашифрованы.
Он имеет библиотеку jQuery для шифрования данных в интерфейсе и библиотеки PHP для дешифрования данных в фоновом режиме.
Используйте хеширующие механизмы для хранения пароля и всегда сравнивайте хешированный пароль, и никто не знает настоящего пароля даже вам. Это очень просто, но оно эффективно. Однако ничто не является полностью безопасным, и есть некоторые способы сломать уровни уязвимости.
Трудно обеспечить связь без trusted third party , однако для вас есть некоторые трюки безопасности:
Каждая конфиденциальная информация должна быть хорошо хэширована или зашифрована с открытым ключом. Обратите внимание: если вы решите шифровать конфиденциальную информацию пользователей с помощью открытого ключа, убедитесь, что пользователь может проверить открытый ключ. Например, вы можете отправить какой-то отпечаток с открытым ключом пользователю через SMS или даже автовызов.
После безопасного входа в транзакцию необходимо создать общий секрет. Процедура генерации может ссылаться на SSL Handshake . Обратите внимание: как только общий секрет генерируется, он должен быть отправлен больше. Единственная его функция заключается в шифровании / расшифровке данных между Server и Broswer
Пусть эти трюки помогут вам