Ответ 1

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

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

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

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

• "Токенизировать логины": если злоумышленник обнюхивает трафик, они будут иметь текстовое имя пользователя/пароль, а затем они могут просто войти в систему с этими новыми учетными данными. (Replay attack)

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

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

Кроме того, вы не можете быть уверены, что источник учетных данных действительно является тем, с кем вы разговариваете. Это означает, что без SSL нет абсолютно уверенности в том, что не происходит Man-In-The-Middle Attack.

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

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

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

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

Ответ 6

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

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

HTTP Digest требует только хэш-операций.

Ответ 7

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

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

Ответ 8

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

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

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

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

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

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

Источник: Wikipedia

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

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

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

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

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

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

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

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

Ответ 9

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

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

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

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

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

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

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

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

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

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

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

Ответ 10

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

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

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

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

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

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

-

Ответ 11

Прежде чем пытаться ответить, я хотел бы упомянуть, что каждый другой ответ здесь касается HTTPS/STS. HTTPS - это битва, ожесточенная, надежная и, вероятно, лучшая ставка - я уверен, что вы устали ее слышать. Теперь я не эксперт по безопасности, но эта проблема - это то, о чем я подумал, и я действительно создал способ. Я никогда не использовал его, и я просил бы всех, как можно больше, выкалывать дыры. Он защищает только от атаки "человек-в-середине".

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

Часть 1: Настройка

• Выберите симметричный шифр, возможно, Rijndael.

• Выберите алгоритм хэширования, SHA256/512 - мои избранные.

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

• В вашей базе данных пользовательские данные должны содержать поле имени пользователя, поле userhash, поле пароля, поле солей, поле ключа и поле Keyhash (плюс все, что вы хотите, я только закрываю соответствующие поля). Я объясню, что должно содержать каждое поле:

  • имя пользователя: фактическое имя пользователя, выбранное во время регистрации.
  • соль: произвольно сгенерированная строка должна содержать не менее 32 символов. Мне нравится делать их 64. Это может быть расточительно, но я параноик. Позвольте называть этот LSALT.
  • пароль: хэш GSALT + фактический пароль + LSALT. Прилагается в этом порядке.
  • userhash: должен содержать хэш имени пользователя GSALT+. Индексировано для скорости. Клавиша
  • : должна содержать случайную строку (это в основном другая соль, но мы будем использовать полупублично)
  • keyhash: содержит хэш GSALT + фактический пароль + ключ. Прилагается в этом порядке.

Часть 2: Регистрация нового пользователя

• В форме регистрации введите имя пользователя, адрес электронной почты, но не пароль.
• После проверки и принятия создайте пароль на стороне сервера и отправьте его по электронной почте.
• В вашей базе данных создайте разные значения, упомянутые в шаге 1 (userhash, пароль, соль, ключ, keyhash и т.д.).

Часть 3: Аутентификация

• Включить глобальную соль с логином.
• При попытке входа в систему:
  • Создать userhash путем хэширования имени GSALT +
  • Создать пропуск через хэширование пароля GSALT +
  • Отправить userhash и passhash на сервер
• На сервере, получающем:
  • Найдите запись пользователя, соответствующую userhash
  • Получите пароль и значение соли из этой записи и убедитесь, что это имя пользователя имеет правильный пароль путем хэширования passhash + user salt (LSALT).
  • Если это соответствует, ваш пользователь аутентифицируется. Произведите nonce (случайное число или строку приличного размера, чтобы его нельзя было догадаться)
  • Зашифруйте nonce, используя значение keyhash в качестве ключа шифрования, и создайте токен с ненужным в нем полезной нагрузкой. Этот токен должен использовать отдельный серверный ключ (см. Схему JWT).
  • Отправляйте ключ, зашифрованный nonce и токен.
• Клиент получает ключ, зашифрованный nonce и токен.
• Клиентский хэш GSALT + фактический пароль + ключ для создания ключа шифрования, необходимого для дешифрования nonce.
• Отменить все другие значения, кроме nonce и токена на стороне клиента.
• При каждом запросе на стороне клиента зашифруйте содержимое, используя ключ nonce. Отправьте зашифрованное содержимое маркером. Не шифруйте токен. Просто отправьте токен в виде отдельного значения из данных запроса.
• Сервер получает зашифрованный запрос и токен, расшифровывает токен, а затем использует nonce для расшифровки содержимого запроса.
• Сервер генерирует ответ, шифрует его с помощью nonce, отправляет его вниз... назад и вперед /etc

Вопросы

• Это вычислительно дорого, с обеих сторон.
• Он не защищает от множества других атак и, скорее всего, более открыт для атаки бокового канала.
• Эта глобальная соль в основном является сделкой навсегда:/
• Я не эксперт по безопасности, это может быть не герметично. "Не сворачивайте свои собственные криптографические схемы" по-разному разгадывается.
• Выделенный достаточно хакер может создать радужный стол или проверить грубую силу для вашего хешированного пароля.
• Он обманывает, потому что мы использовали электронную почту, чтобы обойти зону проблем.

Тем не менее, это забавный мысленный эксперимент! Я надеюсь, что это поможет кому-то (особенно, если это означает, что он подталкивает их к использованию HTTPS)

Ответ 12

Посмотрите "Защищенный протокол удаленных паролей" .

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

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

и

Протокол

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

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

Одна из этих ссылок приводит к "Clipperz" , который является онлайн-менеджером паролей. Он также доступен как издание сообщества на GitHub. Там они размещают "javascript-crypto-library" , которая реализует протокол и "password-manager" , который содержит бэкэнды, написанные на PHP и Python.

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

Изменить 2014/10/24:

Статья в Википедии о SRP содержит еще несколько реализаций. Релевантно для PHP/JS:

• srp-client (JS)
• srp-6a-demo (PHP/JS)

Ответ 13

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

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

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

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

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

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

Сервер делает следующее:

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

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

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

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

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

е. Посылает зашифрованный токен вниз.

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

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

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

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

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

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

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

На каждый запрос сервер получает:

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

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

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

Ответ 14

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

Ответ 15

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

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

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

3) Наконец, я создал хэш частей строки user-agent после успешного входа в систему, содержащего ОС пользователей, браузер (общие не версии) и язык, образуя своего рода вторичный пароль. Если хеш useragent существенно отличается при следующем входе в систему, пользователю предлагается ответить на секретный вопрос. Тогда, если это будет удовлетворительно удовлетворено, новая строка UA будет хеширована и добавлена ​​в список "безопасных машин", так что их не попросят снова с этой машины. Это похоже на механизм, используемый в игровой системе Steam.

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

Ответ 16

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

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

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

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

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

Ответ 17

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

Безопасность Absolut не существует. Недостаток номер один всегда на стороне клиента, с троянами и кейлоггерами. SSL не помогает.

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

2) SMS-сообщения. интересное и доступное решение. Существует много хороших цен от trnasactional sms на рынке, и у каждого есть телефон, способный его получить.

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

Ответ 18

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

Ответ 19

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

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

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

У него есть библиотека jQuery для шифрования данных в интерфейсе и библиотеки PHP для дешифрования данных в фоновом режиме.

Ответ 20

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

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

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

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

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

Взглянув на OAuth 1.0, также неплохая идея.

Ответ 21

жестко защищать связь без trusted third party, однако для вас есть некоторые трюки безопасности:

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

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

Сгенерируйте SHARED SECRET после успешного входа в систему

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

Там ДОЛЖЕН быть двухэтапная проверка, чтобы избежать повторной атаки

Пусть эти трюки помогут вам