Правильное (и, возможно, единственное) решение - использовать HTTPS.Это установит безопасное соединение с сервером для отправки запроса на вход.Поскольку все данные, передаваемые по HTTPS-соединению, зашифрованы, дополнительное шифрование пароля не потребуется.
Предположим, что вы хотите использовать незащищенное соединение (т. Е. HTTP вместо HTTPS).Можно ли использовать шифрование для отправки пароля ... надежно?
Я думаю, что ответ - нет.
В этом сценарии пусть Алиса будет пользователем, Боб будет сервероми Кэрол будет человеком / агентом, пытающимся перехватить пароль.
Предположим, что Алиса отправляет HTTP-запрос для получения страницы входа, а Боб отвечает страницей с некоторым встроенным Javascript, который зашифрует пароль пользователя.Javascript Боба может даже использовать шифрование с открытым ключом, чтобы Кэрол 1 могла расшифровать пароль ... несмотря на знание ключа шифрования.(Можно подумать ...)
К сожалению, это НЕ безопасно.Проблема в том, что Боб отправил страницу, содержащую ваш javascript, в веб-браузер Алисы в открытом виде.Кэрол может использовать известные методы взлома сети, чтобы изменить ответ Боба, чтобы на странице, которую получает Алиса, была другая версия javascript.Эта версия может отправлять пароль в открытом виде или шифровать его другим открытым ключом.Это приведет к тому, что Алиса не сможет войти в систему.Но если Кэрол также может увидеть запрос на вход в систему (потому что он также был отправлен по HTTP), то она может получить пароль Алисы.Действительно, Кэрол может заставить запрос отправляться через HTTP.
Это пример атаки безопасности "человек посередине" (MITM).
Короче говоря, если вы неПри полном обмене по HTTPS любой механизм безопасности, встроенный в страницу входа, может быть побежден.