Как отправить пароль надежно через HTTP с помощью JavaScript в отсутствие HTTPS?
Очень простая проблема все разработчики стоит: Каждый раз, когда пользователь отправляет форму, пароль отправляется через сеть, и это должно быть защищено. Сайт, для которого я разрабатываю, не имеет HTTPS. И при этом владелец не хочет покупать сертификат SSL, и при этом он не заинтересован самоподписанным. Таким образом, я хочу защитить пароль, отправленный через HTTP с помощью JavaScript при представлении формы.
К нетерпеливому downvoters: Как отправить пароль надежно по HTTP? НЕ дает разумного решения, и я нахожусь в другой ситуации.
Если я использую MD5, можно инвертировать ту строку пароля. Что относительно nonce/HMAC? Какая-либо доступная библиотека Javascript для этого? Или у Вас есть какое-либо предложение/подсказка для занятия?Заранее спасибо!
9 ответов
Невозможно безопасно послать пароль , который пользователь может проверить без SSL.
Конечно, можно написать какой-нибудь JavaScript, который сделает пароль безопасным для передачи по проводам с помощью хэширования или шифрования с открытым ключом. Но как пользователь может быть уверен, что сам JavaScript не был подделан человеком в середине до того, как он до них добрался, чтобы послать пароль злоумышленнику вместо сайта, или даже просто скомпрометировать безопасность алгоритма? Единственный способ для них - это быть опытными программистами и попросить их проверить каждую строку вашей страницы и скрипта, чтобы убедиться, что она кошерная, прежде чем вводить пароль. Это не реалистичный сценарий.
Если вы хотите, чтобы пароли были защищены от атак типа "man-in-the-middle", вы должны купить SSL-сертификат. Другого способа нет. Привыкайте к этому.
Если я использую MD5, то можно перевернуть эту строку пароля.
Нет... не тривиально, по крайней мере. Несмотря на то, что MD5 имеет атаки на него, это алгоритм хэширования и, следовательно, необратимый. Придется его перебирать.
Но опять-таки, злоумышленнику не нужно смотреть на ваши MD5. Он может просто саботировать JavaScript, который вы посылаете пользователю для создания MD5
.Решение здесь - вообще не посылать пароль. Использовать вызов/ответ.
В оригинальной форме включайте большой блок случайного текста вместе с ключом. Храните оригинальный случайный текст в сессии на основе ключа на сервере. Когда клиент отправляет форму, используйте JS для хэширования случайного текста и пароля вместе. Затем отправьте имя пользователя, ключ и хэшированный случайный текст на сервер. НЕ отправляйте пароль. На сервере используйте ключ для поиска оригинального случайного текста, выполните ту же операцию хэширования с сохраненным паролем. Если хэш-значение сервера соответствует хэш-значению клиента, то вы знаете, что клиент ввел правильный пароль, никогда не посылая пароль на сервер.
Независимо от того, правильный пароль или нет, срок действия ключа и случайного текста истекает, так что каждый из них является одноразовым.
Для шифрования пароля перед отправкой можно использовать RSA реализацию javascript. (Вот пример RSA в Javascript.)
Но я считаю, что и это, и использование хэш-функции будет уязвимо для повторных атак . Так что будьте осторожны.
Если у вас нет доступа к SSL, MD5 должен быть адекватен, чтобы предотвратить случайное обнаружение паролей (например, в сетевом лог-файле или что-то в этом роде). Все остальное было бы пустой тратой времени. Просто убедитесь, что приложение не дает доступ к конфиденциальной информации (т.е. номерам кредитных карт, медицинской истории и т.д.).
Как и другие комментаторы предполагали, серьезный злоумышленник сможет взломать любой тип безопасности на странице. Даже SSL является небольшим барьером, так как большинство пользователей используют легко угадываемые пароли, повторно используют одни и те же пароли везде, передадут свой пароль любому, кто попросит или может быть обманут в отказе от своего пароля скопированной страницей или телефонным звонком в "техподдержку"
.Решение требует, чтобы клиент мог зашифровать пароль с помощью секретного ключа шифрования, известного только клиенту и серверу.
SSL достигает этого, требуя, чтобы и сервер, и клиентский веб-браузер имели свою собственную асимметричную пару открытых/закрытых ключей, которую они используют для шифрования и передачи случайного ключа сеанса между ними. Остальная часть разговора затем использует этот безопасный ключ сеанса.
Таким образом, вы спрашиваете, как решить ту же проблему, что и SSL, без преимущества наличия секретного ключа, который известен только клиенту и серверу. Я не эксперт, но похоже, что это невозможно или, по крайней мере, нелегко.
Любая имеющаяся у вас передача будет чистой, то есть без SSL ваша критичная информация будет раскрыта. Стоит обсудить этот вопрос с Владельцем сайта. Другими словами, лучше всего принять необходимые меры для усиления передачи данных, а SSL - это один из основных, дешевых шагов, которые вы можете предпринять.
.я не думаю, что проблема здесь в технологии, а в том, как объяснить важность SSL. Обеспечьте их надежными материалами для чтения, я уверен, что их много в Интернете
.Если вы действительно хотите углубиться в это, взгляните на обмен ключами Diffie-Hellman, который был создан для того, чтобы "позволить двум сторонам, не обладающим предварительными знаниями друг о друге, совместно установить общий секретный ключ по небезопасному каналу связи"
, однако я не являюсь экспертом в области криптографии, так что я не до конца понимаю, действительно ли это безопасно, если у злоумышленника есть и клиент (исходный код JavaScript), и транспортный механизм (сниффер пакетов)
.К сожалению, обеспечить безопасность нешифрованного запроса не удастся. Любой, у кого есть доступ к вашему javascript, сможет просто перепрограммировать его/взломать его, а любой, у кого есть сниффер пакетов, сможет наблюдать за незашифрованным трафиком. Эти два факта вместе означают:
Нет SSL? Нет безопасности.