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

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

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

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

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

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

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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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