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

Question

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

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

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

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

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

Answer 6

Это трудно для обеспечения безопасности связи без trusted third party, однако, есть несколько хитростей для вас:

НЕ ПРЕДОСТАВЛЯЙТЕ конфиденциальную информацию пользователей общедоступной сети.

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

Создание общего секрета после успешного входа в систему

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

.

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

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

Answer 7

Посмотрите на "Протокол безопасного удаленного пароля" .

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

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

и

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

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

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

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

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

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

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

Answer 8

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

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

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

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

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

Answer 9

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

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

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

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

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

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

---

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

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

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

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

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

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

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

---

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

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

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

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

---

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

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

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

---

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

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

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

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

Answer 10

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

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

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

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

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

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