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

Question

Я реализует авторизацию в моем GWT приложения, и в настоящий момент это происходит следующим образом:

1. пользователь подписывается, поставив свои учетные данные в форме, и Я отправляю их в ясный текст на сервер.
2. Код сервера хэширует полученный пароль с использованием BCrypt и помещает хэш в базу данных.
3. Когда пользователь входит в систему, его пароль отправляется с очисткой на сервер, который проверяет его на сохраненный хэш.

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

Я был googling весь день для этого, и кажется, что Интернет вполне единодушно, когда дело доходит до этого - видимо, от шифрования пароля на стороне клиента ничего не получится. This, this и this - всего лишь несколько примеров обсуждений и страниц, которые я привел, но есть много и много других, говорящих одно и то же.

Этот вопрос, в свете всего этого, может показаться немного ненужным, но я надеюсь, что у кого-то у меня будет другой ответ.

Что я могу сделать, , если SSL не вариант на данный момент, чтобы облегчить свое мнение по этому поводу? Есть ли что-нибудь, что можно сделать или будет внедрено какая-то схема шифрования-шифрования-сервера-сервера, просто будет трудоемкой слабой мертвой ногой?

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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