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

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

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

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

Если вы действительно хотите глубоко погрузиться в это, посмотри обмен ключами Диффи-Хеллмана который был создан ,чтобы"позволить двум сторонам, которые не имеют предварительного знания друг о друге, совместно установить общий секретный ключ по небезопасному каналу связи"

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

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

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

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

нет SSL? Никакие ценные бумаги.

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

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

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

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

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

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

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

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

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

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

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

-- испанский -- Мне Акаба-де-ocurrir алго кы пуйде, служи, но не се Си realmente море алго-Сегуру. Пр Медио де РНР puedes генерировать и читать перевода ООН algoritmo кы Кри ООН строку собственная база Аль отметка о алго еще, Г colocar разложив Эста Кадена Ан-Эль HTML-код.

Примечание дие Квандо ушей описать УНА contraseña в организации Кампо типо ввода пароля, кон ООН отладки нет SE пуйде Вер Эль доблести ке tecleo Эль-пользователь (не се Си exista манера перо не quise investigar более), АСИ дие Подемос utilizar Ла contraseña дие Эль-пользователь escribió Комо палабра Клаве пункт encriptar Ла Кадена де текст кы previamente habiamos generado кон РНР, пр medio de un algoritmo en JS. Sería algo así como encriptar lo encriptado. Posteriormente Ло дие estariamos сайт enviado не sería Ла contraseña tecleada, си не Эста "последний час" Кадена resultante.

Buscando ООН контра, Ло едином ке се мне ocurra Эс дие Эль atacante tendrá que с dedicarle мучо тьемпо пара tratar де encontrar Эль agoritmo ке creamos пор Медио де РНР г подер decriptar Ла Кадена окончательной, о tendrá que с hackear Эл база пункт acceder Аль РНР г obtener Эл algoritmo.

Эсто Эс Соло УНА идея, пор Ло ке Си pueden decirme Como в Эсто пуйде не сер-Сегуру, ЮВ Лос agradecería.

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

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