Содержание

php — Безопасная авторизация — Stack Overflow на русском

Вопрос задан

Изменён 4 года назад

Просмотрен 4k раз

Пишу авторизацию на php, но я не знаю насколько она безопасна.

Принцип работы:

  1. POST данные отправляются на сервер.
  2. Проверяются логин и пароль.
  3. Если есть такой пользователь, добавляем его в бд ( ID пользователя, первые 3 цифры IP адреса ).
  4. Сохраняем ID авторизации в сессию.
  5. Авторизация пройдена успешно, но это не все.
  6. Каждую минуту меняется значения AuthID ( ID авторизации ).

Вот скажите насколько такой принцип БЕЗОПАСЕН?

Хакер же за 1 минуту не сможет же перехватить значения AuthID, и сменить их?

  • php
  • авторизация

Хакер может за несколько миллисекунд перехватить.

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

Отправитель на посылку(внутри — логин, пароль) вешает свой замок(то есть, шифрует ее). Получатель молча шифрует ее повторно уже своим ключом и отправляет обратно. Отправитель расшифровывает свой шифр и опять шлет серверу. Сервер открывает свой шифр и получает логин и пароль. Итог: ни логин ни пароль не засветились. При любой попытке вклиниться, письмо не откроется на какой-то стороне.

Естественно, шифрование должно быть надежным.

11

3 цыфри

цифры

Проверяется логин и пароль.

На что проверяется?

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

Убедились еще раз в том что данные корректны.

Сделали запрос в БД, (да, нет) поглядели, если да, то куку ему, саму куку можно в БД записать(если есть огромное желание)

Почему каждую минуту у тебя меняется AuthID для чего?

Вот скажите насколько такой принцип БЕЗОПАСЕН?

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

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

Зарегистрируйтесь или войдите

Регистрация через Google

Регистрация через Facebook

Регистрация через почту

Отправить без регистрации

Почта

Необходима, но никому не показывается

Отправить без регистрации

Почта

Необходима, но никому не показывается

Нажимая на кнопку «Отправить ответ», вы соглашаетесь с нашими пользовательским соглашением, политикой конфиденциальности и политикой о куки

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

 design@acrit. ru

+7 495 008 8452

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

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

Источник: 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.

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

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

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

Загрузка…


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

13 Лучшая система входа на PHP

Найдите коллекцию отобранных вручную бесплатных систем входа на PHP. Все сценарии разработаны с использованием PHP, MySql (база данных), HTML и CSS. Ниже представлены мои лучшие коллекции скриптов PHP Login. Большинство сценариев разработаны с использованием шаблонов MVC и также охватывают безопасность. В некоторых учебниках есть возможность загрузки, а в других есть фрагмент кода.

Изображение: Система безопасного входа с PHP и MySQL
Автор
  • Дэвид Адамс
  • 4 января 2021 г.
Ссылка

Код

Сделано с
  • PHP / MySql / HTML / CSS
О коде

Система безопасного входа с PHP и MySQL

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

Изображение: PHP Система входа в MySQL
Автор
  • tutorialrepublic
Link

Code

Made with
  • PHP / MySql / HTML / CSS
About the Code

Creating a User Login System with PHP and MySQL

In this tutorial you will learn как создать простую систему регистрации и входа пользователей с использованием PHP и MySQL.

Изображение: Build Simple Login in PHP
Автор
  • Красимир Христозов
  • 28 декабря 2018
Ссылка

Код

Сделано с помощью
  • PHP/MySql/CSS/HTML
О коде

Создание простого входа в PHP

В этой статье я покажу вам, как создать вход на PHP Системное приложение с нуля (только с единственной зависимостью от внешней библиотеки — DotEnv, поэтому мы можем хранить наши секреты в файле . env вне репозитория кода). Приложение обеспечивает вход/выход пользователя, регистрацию нового пользователя и форму «Забыли пароль», используя простой API OAuth 2.0 от Okta… С тегами crud, react, PHP, laravel.

Изображение: Операция CRUD в PHP
Автор
  • WebortoryStuff
  • Jul-20-2020
Link

Код

Сделано с
  • PHP / MySQL / HTML / CSS19
    7024. Операция CRUD В PHP

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

    Дополнительная информация: операция CRUD в PHP в GitHub

    Изображение: Как построить форму входа в систему PHP с использованием сеансов
    Автор
    • Джон Моррис
    • декабрь 9, 2017
    Link

    Код

    Сделано с
      9
    • . PHP / MySql / HTML / CSS
    О коде

    Как создать форму входа в систему PHP с использованием сеансов

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

    Изображение: Создайте систему входа в систему с использованием HTML, PHP и MySQL
    Автор
    • Neil Agarwal
    • 20, 2020
    Link

    Сделано с
    • PHP / MySQL / HTML
      • О коде

      Создание системы входа с использованием HTML, PHP и MySQL

      В этой статье вы узнаете об основных функциях регистрации и входа в систему с помощью HTML, PHP и MySQL.

      Изображение: PHP 8 MySQL Tutorial: Build Login and User Authentication System
      Автор
      • Digamber
      • 12 января, 2021
      Ссылка

      Код

      Сделано с
      • PHP / MySQL / HTML
      ОБОРУ

      Создайте систему аутентификации и входа пользователей PHP 7 с MySQL и Bootstrap 4, используя подход процедурного программирования.

      Дополнительная информация: GitHub

      Изображение: Создание системы регистрации и входа с помощью PHP и MySQL
      Автор
      • Редакция SpeedySense
      • 15 декабря 2019 г.
      Ссылка

      Код

      Сделано с
      • PHP / MySQL / HTML / CSS
      о коде

      Create A REGISTINININIT SYSTER и PHORSININIT SIGDINININININININ и MySQL

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

      More info: Download

      Image: Complete user registration system using PHP and MySQL database
      Author
      • Awa Melvine
      Link

      Code

      Made with
      • PHP / MySql / HTML / CSS
      О коде

      Полная система регистрации пользователей с использованием базы данных PHP и MySQL

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

      Image: How to Build a Secure Login Page in PHP

      Advertisements

      Author
      • Sean Higgins
      • Jun 12, 2020
      Link

      Code

      Made with
      • PHP / MySql / HTML / CSS
      О коде

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

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

      Image Сегодня вы точно узнаете, как создать класс входа и аутентификации в PHP.
      Автор
      • Alex Web разработка
      • 5 июля 2020 г.
      Ссылка

      Код

      Сделано с
      • PHP / MySQL
      О коде

      PHP Login с SENSSCL и MYSQL: TUTERAL

      PHP с SESENS и MYSQL: TUTORAL

      .

      Полный класс PHP, который вы можете скачать прямо сейчас (с примерами). Вход с помощью MySQL и Sessions, регистрация учетной записи, защита паролем и многое другое».

      Подробнее: Скачать

      Изображение: Создайте систему входа в систему с использованием базы данных PHP и MySQL
      Автор
      • Clever Techie
      • 1 февраля 2017
      Link

      Код

      Сделано с
      • Php / mysql / mysql / mysql / mysql / mysql / mysql / mysql / mysql / mysql / mysql / mysql / mysql / mysql / mysql / mysql / mysql / mysql / mysql / mysql / mysql / mysql / mysql / mysql / mysqu HTML
      О коде

      Создание системы входа в систему с использованием PHP и базы данных MYSQL

      Создание системы входа в PHP с использованием базы данных MYSQL

      Изображение: Создание системы входа в PHP
      Автор
      • Monty Shokeen
      • ноября 1920 г.
      Link

      Код

      Сделано с
      • PHP / MySQL / HTML / CSS
      Облизочно и система регистрации очень полезна, когда мы хотим хранить информацию о пользователях нашего сайта. Это относится ко всему: от образовательных веб-сайтов, на которых могут храниться сведения об успеваемости и оценках, до веб-сайтов электронной коммерции, на которых хранится информация о прошлых покупках клиентов.

      Иконки, сделанные srip с www.flaticon.com

      Теги: loginlogin systemphp loginphp scriptscript

      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).

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

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

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

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

      25

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

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

      Изменить: (о рисках)

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

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

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

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

      5

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

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

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

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

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

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

      2

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

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

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

      0

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

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

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

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

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

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

      17

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

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

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

      4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      1

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

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

      2

      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, и это лишь некоторые из них. Вот статья.

      1

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

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

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

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

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

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

      —

      1

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

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

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

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

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

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

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

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

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

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

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

      0

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

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

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

      и:

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

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

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

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

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

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

      • srp-клиент (JS)
      • srp-6a-демо (PHP/JS)

      2

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

      5

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

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

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

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

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

      4

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

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

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

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

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

      6

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

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

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

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

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

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

      3

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

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

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

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

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

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

      4

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

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

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

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

      2

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

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

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

      No related posts.