Авторизация php безопасная: Безопасный метод авторизации на PHP / Хабр

Содержание

Как настроить безопасную авторизацию

[email protected]

+7 495 008 8452

Анализ

Проект

Дизайн

Маркетинг

Разработка

Наполнение

Техподдержка

Веб-студия АКРИТ. разработка модулей и сайтов интернет магазинов на 1С Битрикс
Кладовка программиста
База знаний
Проактивная защита
Безопасность и сохранность данных
org/ListItem»>Как настроить безопасную авторизацию

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

Источник: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=35&LESSON_ID=3081

Штатный инструмент безопасной авторизации

Пароли для большинства сайтов передаются в открытом виде, если не используется

SSL

SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, который подразумевает более безопасную связь. Он использует асимметричную криптографию для аутентификации ключей обмена, симметричное шифрование для сохранения конфиденциальности, коды аутентификации сообщений для целостности сообщений.

Подробнее…

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

Безопасная авторизация — функция, обеспечивающая зашифрованную передачу пароля пользователя. Шифрование пароля не является заменой SSL. Безопасная авторизация защищает от перехвата пароля только при прослушивании трафика.

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

Подключение

Подключается Безопасная авторизация в настройках главного модуля на закладке Авторизация:

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

По нажатию на Сгенерировать ключ происходит генерация ключа

RSA

RSA (буквенная аббревиатура от фамилий Rivest, Shamir и Adleman) — криптографический алгоритм с открытым ключом.

Размер ключа зависит от библиотек, установленных на сервере. По умолчанию используется модуль PHP openssl, который создаёт 1024-битный ключ. Его и рекомендуется использовать. Если модуль не установлен, то возможно использование bcmath с генерацией 512-битного ключа. Если нет ни того, ни другого модуля, включить шифрование нельзя.

Генерация ключа выполняется один раз. Повторную генерацию производить необходимо, если есть подозрения в компрометации ключа.

Внимание! На браузерах клиентских компьютеров должно быть разрешено использование Javascript.

Алгоритм работы

Вместе с формой авторизации клиенту передается открытый ключ.

Перед отправкой формы авторизации, Javascript перехватывает отправку, зашифровывает пароль, с использованием открытого ключа, и отправляет на сервер.

Сервер принимает шифротекст, расшифровывает его с использованием секретного ключа, и проводит аутентификацию пользователя.

Назад в раздел

Подписаться на новые материалы раздела:

Загрузка…

Веб студия «АКРИТ»

Узнать
больше

Рассылка

Услуги

Внедрение, разработка, техподдержка
Настройки торговых площадок
Экспертиза производительности
Пакет услуг по переходу на новые версии модуля
Пакеты услуг
Продление решений
Сопровождение и поддержка сайтов

Компонент Security | Symfony

Компонент Security предоставляет полную систему безопасности для вашего
веб-приложения. Он поставляется с инструментами для аутентификации, используя
базовую HTTP-аутентификацию, интерактивную форму входа в систему или сертификат
входа в систему X.509, но он также позволяет вам реализовать вашу собственную
стратегию аутентификации. Более того, компонент предоставляет способы для
авторизации аутентифицированных пользователей, основываясь на их ролях, и содержит
продвинутую систему СКД.

Alternatively, you can clone the https://github.com/symfony/security repository.

Note

Если вы устанавливаете этот компонент вне приложения Symfony, вам нужно
подключить файл vendor/autoload.php в вашем коде для включения механизма
автозагрузки классов, предоставляемых Composer. Детальнее читайте в
этой статье.

Компонент Security делится на четыре меньших подкомпонента, которые могут
быть использованы отдельно:

symfony/security-core: Предоставляет все общие функции безопасности, от аутентификации до авторизации,
и от шифрования паролей до загрузки пользователей.
symfony/security-http: Интегрирует базовый подкомпонент с протоколом HTTP, для обработки HTTP запросов
и ответов.
symfony/security-csrf: Предоставляет защиту от CSRF атак.
symfony/security-acl: Предоставляет тонко настраиваемый механизм разрешений, основанный на списках
контроля доступа.

Как обеспечить безопасность аутентификации php?

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

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

Обычно аутентификация на сервере требует использования имени пользователя и пароля. Другими способами аутентификации могут быть карты, сканирование сетчатки глаза, распознавание голоса и отпечатки пальцев.

Аутентификацию следует использовать всякий раз, когда вы хотите точно знать, кто использует или просматривает ваш сайт. Веб-вход — это основной метод аутентификации Бостонского университета. Другие коммерческие веб-сайты, такие как Amazon.com, требуют, чтобы люди входили в систему перед покупкой продуктов, чтобы они точно знали, кто их покупатели.

Безопасная аутентификация в PHP

uLogin

uLogin — это библиотека PHP для добавления возможностей безопасного входа и аутентификации в веб-приложения. uLogin предоставляет инструменты для защищенных пользовательских сессий, хранения паролей, логинов. Он использует различные меры для противодействия различным видам онлайн- и офлайн-атак, а также для ограничения ущерба в случае нарушения. Расширенные возможности, такие как функция «запомнить меня», поддержка двухфакторной аутентификации, распознавание попыток грубой силы и поддержка нескольких пользовательских баз данных в дополнение к множеству функций безопасности, делают ее многофункциональной, безопасной и гибкой системой аутентификации. Инструменты для простой интеграции предотвращения XSS/CSRF/воспроизведения в любую другую часть вашего веб-сайта предоставляются в виде компактной, но универсальной библиотеки nonce.

OpenID

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

PHPass

PHPass — это легкая библиотека хеширования паролей с переменной стоимостью, использующая bcrypt. Переменная стоимость означает, что вы можете позже увеличить «стоимость» хеширования паролей, чтобы плавно повысить безопасность без необходимости аннулировать ранее хешированные пароли пользователей. Размер поля, используемого для хранения хэша, остается постоянным даже при увеличении «стоимости» из-за увеличения не размера хэша, а количества итераций, необходимых для его создания.

PHPAuth

PHPAuth — это безопасный класс аутентификации пользователей для веб-сайтов PHP, использующий мощную систему хеширования паролей и блокировку атак для обеспечения безопасности вашего веб-сайта и пользователей. PHPAuth находится в стадии разработки и не предназначен для людей, которые не умеют программировать, он предназначен для людей, которые знают, что делают

Как защитить аутентификацию в PHP?

Создать таблицу базы данных
Создание HTML-формы входа пользователя
Добавление стилей в форму входа
Подключиться к базе данных
Логика PHP для входа пользователя
Затем Logout.php

Как это работает?

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

Фото из Wright Studio

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

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

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

В случае двух клиентов, которым требуется безопасное сквозное (e2e) шифрование, существует проверенный протокол Signal с открытым исходным кодом, который получил несколько портов с открытым исходным кодом на github и получил широкое распространение в популярных приложениях, таких как WhatsApp. Нет необходимости создавать свои собственные, эти протоколы хорошо работают по определенной причине.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог — вам необходимо использовать HTTPS, чтобы гарантировать безопасность сайта.

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

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

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

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

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

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

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

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

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

Создайте пару открытый/закрытый ключ, используя асимметричный шифр.

Создайте симметричный ключ на сервере.

Отправьте открытый ключ на сторону клиента.

Создать случайный ключ для клиентской части симметричного шифрования.

Зашифруйте этот случайный ключ, используя клиентскую часть открытого ключа.

Отправить зашифрованный ключ на сервер.

Сервер выполняет следующие действия:

а. Расшифровывает случайный симметричный ключ с помощью закрытого ключа.

б. Создает токен, содержащий сгенерированный ключ клиента.

в. Подписывает токен.

д. Шифрует токен с помощью симметричного ключа сервера.

эл. Шифрует уже зашифрованный токен с помощью ключа, сгенерированного клиентом.

ф. Отправляет зашифрованный токен вниз.

Клиент получает этот токен и делает следующее:

а. Расшифровывает токен сгенерированным им ключом.

б. Сохраняет расшифрованный токен.

в. На этом этапе сохраненный токен шифруется только с помощью симметричного ключа сервера.

На каждом от клиента к серверу:

а. Зашифруйте исходящие данные с помощью ключа, сгенерированного клиентом.

б. Отправить токен + зашифрованные данные

При каждом запросе сервер получает:

a. Расшифруйте токен с помощью симметричного ключа сервера.

б. Проверьте подпись.

в. Расшифруйте данные, используя сгенерированный клиентом ключ, хранящийся в токене.

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

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

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

Что делать?

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

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

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

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

Я хочу полностью раскрыть, что я НЕ профессионал в области безопасности, а просто энтузиаст. Я не рекомендую делать это для проекта производственного уровня или для чего-то другого, кроме вашего собственного назидания. Вам ОБЯЗАТЕЛЬНО следует ознакомиться с этим сообщением SO, в котором дается отличное объяснение препятствий при настройке собственного протокола безопасности.

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

HTTPS поддерживается всеми основными современными браузерами. Даже в этой реальности время загрузки HTTPS медленнее, чем обычный HTTP. Без обширного производства весьма вероятно, что ваша альтернативная реализация будет менее безопасной, но значительно медленнее. Это будет недостатком любой доморощенной реализации, если вы не используете функции браузера, что возвращает нас к использованию TLS, который использует современный HTTPS.
Если вам удастся зашифровать свой пароль без TLS на стороне браузера с помощью Javascript настолько непредсказуемым образом, что атака MiTM будет затруднена, не останавливайтесь на достигнутом. Вы также должны защищать данные, которые вы отправляете туда и обратно. В противном случае зашифрованный пароль действительно не имеет значения. Конечно, злоумышленник может не знать пароль bobsmith209, но он ему и не нужен, потому что он может прослушивать каждое действие в сети. Он знает, что такое бобсмит209входит в систему, вероятно, может отследить его IP и любые другие конфиденциальные данные, которые вы отправляете туда и обратно.
Независимо от того, какие меры безопасности вы принимаете, безопасность всегда на высоте. Итак, одна вещь, которую вы можете сделать сразу же, — убедиться, что вы зашифровали свои данные в базе данных, а также требуете надежных паролей.

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

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

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

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

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

Что ты умеешь делать? Теоретически?

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

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

—

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

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

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

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

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

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

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

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

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

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

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

Взгляните на «Протокол защищенного удаленного пароля» .

Вместо того, чтобы формулировать это самостоятельно, позвольте мне процитировать их веб-сайт:

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

и:

[The] протокол сочетает в себе методы доказательств с нулевым разглашением с протоколами обмена асимметричными ключами и предлагает значительно улучшенную производительность по сравнению со сравнительно надежными расширенными методами, которые противостоят атакам с украденным верификатором, таким как расширенный EKE или B-SPEKE.

Хотя Стэнфордский университет сам не предоставляет реализации для PHP и JavaScript, они ссылаются на некоторые сторонние реализации.

Одна из этих ссылок ведет на «Клипперз» — онлайн-менеджер паролей. Он также доступен как версия для сообщества на GitHub. Там они размещают свою «javascript-крипто-библиотеку», которая реализует протокол и сам «менеджер паролей», содержащий бэкенды, написанные на PHP и Python.

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

Редактировать 24.10.2014:

В статье Википедии о SRP перечислены еще несколько реализаций. Актуально для PHP/JS:

srp-клиент (JS)
srp-6a-демонстрация (PHP/JS)

Лучшее решение, которое я видел для несколько безопасных HTTP-соединений, — это использование Javascript-реализации md5sum (или другого хэша), чтобы избежать передачи пароля в виде открытого текста. Вы можете создать обработчик отправки формы в Javascript, который заменяет поле пароля хэшем исходного значения. Это добавляет скромную степень безопасности незащищенному соединению, но для правильной работы требуется Javascript, работающий в браузере.

Я полагаю, вас волнует безопасная передача пароля на сервер? Мой ответ: не передавать пароли на сервер 🙂

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

Предложение:

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

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

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

1) Во время регистрации пользователи должны иметь надежные пароли (для предотвращения словарных атак), секретный вопрос/ответ и стандартную проверку электронной почты (как доказательство того, что это реальный человек)

2) Во время входа в систему, после 5 неудачных попыток входа ( не ранее) отображается капча для предотвращения атак методом грубой силы.

3) Наконец, я создал хэш частей строки пользовательского агента после успешного входа в систему, содержащий ОС пользователя, браузер (общий, а не версии) и язык, формируя своего рода вторичный пароль. Если при следующем входе в систему хэш агента пользователя значительно отличается, пользователю предлагается ответить на контрольный вопрос. Затем, если ответ будет удовлетворительным, новая строка UA хешируется и добавляется в их список «безопасных машин», чтобы их больше не запрашивали с этой машины. Это похоже на механизм, используемый игровой системой Steam.

Это очень успешно использовалось более года с примерно 700 пользователями, и у него было дополнительное преимущество, заключающееся в предотвращении «совместного использования логина» — проблемы, когда несколько пользователей использовали одни и те же учетные данные для удобства!

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

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

1) Генераторы токенов : их используют банки, затем их использует Blizzard. Это может быть устройство или приложение. Ну.. дорого.

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

3) Если вам нужно использовать HTTP, вы можете принудительно использовать стороннюю службу oauth, например гугл или фейсбук . Это лучшее, что вы можете сделать без генератора токенов.

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

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

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

На стороне сервера используйте имя пользователя для поиска пароля и проверки зашифрованной строки.

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

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

Взглянуть на OAuth 1.0 тоже неплохо.

Если вы не можете использовать HTTPS или не хотите использовать HTTPS, рассмотрите возможность использования jCryption. jCryption предлагает шифрование данных, отправляемых через HTTP-запросы (POST, GET и т. д.).

Вы можете проверить технику здесь: http://www.jcryption.org/#examples

Если вы используете Firebug, вы увидите, что все данные зашифрованы.

Он имеет библиотеку jQuery для шифрования данных на внешнем интерфейсе и библиотеку PHP для расшифровки данных на внутреннем.

трудно обеспечить безопасность связи без доверенной третьей стороны , однако есть несколько приемов безопасности для вас:

НЕ раскрывайте конфиденциальную информацию пользователей в общедоступную сеть.

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

imacrosoft.ru