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

Question

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

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

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

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

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

Что я могу сделать, , если ssl не подходит на этом этапе , чтобы облегчить мне этот вопрос? Есть ли что-то, что нужно сделать, или реализация какой-то схемы client-encrypt-server-decrypt-просто будет занимать много времени, слабая и беспомощная?

Answer 1

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

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

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

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

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

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

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

Answer 2

Если SSL не подходит, тогда вам явно не важна безопасность;)

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

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

Answer 3

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

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