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

Ответ 1

Невозможно отправить безопасный пароль , который пользователь может проверить без SSL.

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

Если вы действительно хотите глубоко погрузиться в это, посмотрите на Diffie-Hellman key exchange, который был создан, чтобы "разрешить двум сторонам, которые не имеют предварительного знания друг друга о совместном создании общего секретного ключа по небезопасному каналу связи"

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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

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

Ответ 10

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

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

Таким образом, злоумышленники не имеют внутри кода 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.

Примечание: 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 researchar 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. Сериал algo así como encriptar lo encriptado. За более подробной информацией обращайтесь, пожалуйста, без комментариев. Tcleada, 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.

Ответ 11

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

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