Как безопасно отправить пароль по HTTP с использованием Javascript при отсутствии HTTPS?

Question

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

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

Если я использую MD5, можно изменить эту строку пароля на противоположную.А как насчет одноразового использования / HMAC?Есть какая-нибудь доступная библиотека Javascript для этого?Или у вас есть какое-либо предложение / подсказка для решения?Заранее спасибо!

Answer 1

Невозможно безопасно отправить пароль что пользователь может проверить без SSL.

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

Если вы хотите, чтобы пароли были защищены от атак «человек посередине», вам необходимо купить сертификат SSL.Другого пути нет.Привыкайте к этому.

Если я использую MD5, можно изменить эту строку пароля.

Нет...по крайней мере не тривиально.Несмотря на то, что MD5 имеет атаки на него, это алгоритм хеширования, и поэтому он необратим.Вам придется применить грубую силу.

Но опять же, злоумышленнику «человек посередине» не нужно смотреть на ваши MD5.Он может просто саботировать JavaScript, который вы отправляете пользователю для создания MD5.

Answer 2

Решение здесь — вообще не отправлять пароль.Используйте вызов/ответ.

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

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

Answer 3

Если вы ДЕЙСТВИТЕЛЬНО хотите углубиться в это, посмотрите Обмен ключами Диффи-Хеллмана который был создан, чтобы «позволить двум сторонам, не имеющим предварительного знания друг о друге, совместно установить общий секретный ключ по незащищенному каналу связи»

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

Answer 4

Вы можете использовать реализацию JavaScript RSA для шифрования пароля перед отправкой.(Вот пример RSA в Javascript.)

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

Answer 5

К сожалению, не будет возможности обеспечить безопасность незашифрованного запроса.Любой, у кого есть доступ к вашему javascript, просто сможет перепроектировать его/подделать, а любой, у кого есть анализатор пакетов, сможет наблюдать за незашифрованным трафиком.Эти два факта вместе означают:

Нет SSL?Никакой безопасности.

Answer 6

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

Answer 7

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

Answer 8

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

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

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

Answer 9

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

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

Answer 10

-- Русский -- я кое в чем разбираюсь, но я не знаю, может ли это быть действительно безопасно.Если вы можете поместить свою форму в php-файл, то вы можете создать алгоритм для создания строки, основанной на времени или на чем-то другом, а затем поместить эту строку в ваш html.

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

Таким образом, у злоумышленников нет всего внутри js-кода, поэтому им нужно будет узнать алгоритм, который вы создаете, чтобы расшифровать его.

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

-- Испанский -- Se me acaba de ocurrir algo que puede servir, pero no se si realmente sea algo seguro.Por medio de php puedes generar un algoritmo que cree un string en base al timestamp o algo más, y después colocar esta cadena en el html.

Note que cuando alguien escribe una contraseña en un campo input tipo password, con un debug no se puede ver el valor que tecleo el usuario (no se si exista manera pero no quise investigar más), asi que podemos utilizar la contraseña que el usuario escribió como palabra clave para encriptar la cadena de texto que previamente habiamos generado con php, por medio de un algoritmo en JS.Sería algo así como encriptar lo encriptado.Posteriormente lo que estariamos enviado no sería la contraseña tecleada, si no esta última cadena resultante.

Buscando un contra, lo único que se me ocurra es que el atacante tendrá que dedicarle mucho tiempo para tratar de encontrar el agoritmo que creamos por medio de php y poder decriptar la cadena final, o tendrá que hackear el servidor para acceder al php y obtener el algoritmo.

Esto es solo una idea, por lo que si pueden decirme como esto puede no ser seguro, se los agradecería.

Answer 11

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

Я думаю, что самый безопасный способ — вместо хранения H(пароль), где H — выбранная вами хеш-функция, сохраните g^H(пароль) т.е.используйте пароль в качестве закрытого ключа для обмена ключами Диффи-Хеллмана.(Вам также, вероятно, следует использовать случайный g для разных пользователей — это станет вашей солью.) Затем для проверки вы генерируете nonce b, отправляете пользователю g^b и вычисляете (g^H(пароль))^б.Пользователю не нужно знать g — ему нужно только вычислить (g^b)^H(пароль) = (g^H(пароль))^б.Теперь у вас есть номер, который знают обе стороны. если только пользователь ввел правильный пароль, и построение доказательства с нулевым разглашением «запрос-ответ», основанное на знании правильного числа, тривиально, в то время как случайное число, используемое в качестве «закрытого ключа» сервера, делает этот подход невосприимчивым к атакам с повторным воспроизведением.