Шифрование пароля на стороне клиента GWT/Javascript

Для входа SSL должен быть вашим вариантом, даже на этом этапе. Если это только для входа в систему, вам не нужна дорогая ферма SSL, но, по крайней мере, вы защищаете (используйте для всех) пароль, даже если ясно, что оставшаяся связь не защищена ^{[ *]}. Это может означать, что вам нужно купить сертификат только для одного сервера входа, что опять же может сэкономить вам много денег, в зависимости от поставщика сертификата.

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

Если это все еще не вариант, вы можете подумать о входе через OpenID, точно так же, как stackoverflow делает.

Не может быть какого-либо безопасного обмена данными через незащищенные носители без некоторого общего секрета, обычно предоставляемого корневыми сертификатами, установленными в браузере (кстати, это забавно/ пугает то, что браузеры и даже целые операционные системы обычно загружаются по HTTP). Другие системы, например. PGP опирается на ранее установленное доверие в "Web Of Trust", но это просто другая форма предварительно разделенных секретов. Нет никакого способа обойти это.

^{[*] Использование SSL для всего, к сожалению, сопряжено с дополнительными практическими проблемами: 1) страницы загружаются намного медленнее, особенно если на странице много элементов. Это происходит из-за вызванных SSL циклов обмена данными и возникающей в результате задержки, с которой вы не можете справиться даже с самой быстрой SSL-фермой. Проблема смягчается, но не полностью устраняется поддерживающими соединениями. 2) Если ваша страница содержит элементы с иностранных, не-HTTPS-сайтов (например, изображения, вставленные пользователями), многие браузеры будут отображать предупреждения, которые очень расплывчато отражают реальную проблему безопасности и поэтому обычно неприемлемы для защищенного сайта.}

Несколько дополнительных соображений (не рекомендация)

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

Если SSL не вариант, то вы, очевидно, недостаточно заботитесь о безопасности;)

А если серьезно - как вы упомянули, шифрование пароля на стороне клиента - не очень хорошая идея. На самом деле, это очень плохо. Вы не можете доверять клиентской стороне для джека - что, если злоумышленнику удастся изменить код JS (через XSS или когда он был отправлен по сети), так что ваша хэш-функция MD5 или любая другая просто передает проход в открытом виде? Не говоря уже о том, что вы должны использовать хороший, надежный, защищенный метод шифрования, такой как bCrypt — что-то, что работает медленно на клиенте и, как упоминалось ранее, не совсем повышает безопасность приложения.

Вы могли бы попытаться обойти некоторые из этих проблем: отправив хэш-библиотеку каким-нибудь безопасным способом (если бы это было возможно, нам бы не пришлось сейчас возиться со всем этим, не так ли?), каким-то образом разделив общий секрет между сервером и клиентом и использовать его для шифрования... но суть такова: по возможности используйте HTTPS (в GWT трудно смешивать HTTPS и HTTP) и оправданно (если пользователь достаточно глуп, чтобы использовать один и тот же пароль для вашего приложения, не связанного с безопасностью, и для своей банковской учетной записи, то весьма вероятно, что он использовал один и тот же пароль на нескольких другие сайты, любой из которых может привести к перехвату пароля). Другие средства просто заставят вас думать, что ваше приложение более безопасно, чем оно есть на самом деле, и сделают вас менее бдительными.

Рассмотрите возможность использования SRP.

Но это все равно не поможет, если человек посередине отправит вам злой javascript, чем simpy отправит копию вашего пароля на сервер злоумышленников.