Отправка паролей через ajax

Question

с учетом следующего сценария: У нас есть HTML-форма для изменения пароля учетной записи. Это выглядит так:

CurrentPassword:   __________________
NewPassword:       __________________
NewPasswordAgain:  __________________

Мы хотим отправить этот запрос с помощью вызова ajax. Если мы отправим его и уйдем с нашего компьютера (не выходя из системы и оставаясь на той же самой странице), кто-то может открыть инспектор веб-наборов (или firebug) и увидеть что-то вроде этого:

http://cl.ly/3y213W1q0U2y2e251k0O

Каким было бы ваше решение для повышения безопасности? Возможно ли здесь использовать вызов ajax или лучше использовать «обычную» HTML-форму, которая после отправки перезагружает всю страницу?

Answer 1

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

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

Answer 2

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

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

Что-то, что вы должны сделать, это обновить страницу всякий раз, когда пользователь нажимает кнопку «Выйти». Это должно очистить все предыдущие сетевые данные.

Менее удачные варианты - шифрование, запутывание и хеширование пароля перед его отправкой.

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

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

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

Answer 3

Чтобы сделать это безопасным без использования SSL, хэшируйте пароли на клиенте, используя SHA-2 .Хотя это защитит сам пароль, оно не защитит кого-либо от перехвата пароля hash .Таким образом, вы не можете просто пройти аутентификацию с помощью хешированного пароля.

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

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

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

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

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

Answer 4

Зашифруйте пароль на транспорте и убедитесь, что вы делаете вызовы по SSL!

Answer 5

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

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

Вот одна библиотека, которую я нашел с быстрым поиском. (отказ от ответственности: я не проверял это, но выглядит довольно неплохо)

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