Шифрование пароля на стороне клиента GWT / Javascript
Я реализую авторизацию в своем приложении gwt, и на данный момент это делается следующим образом:
- Пользователь регистрируется, помещая его учетные данные в форме, и я отправляю их в виде открытого текста на сервер.
- Серверный код хеширует полученный пароль с помощью BCrypt и помещает хеш в базу данных.
- Когда пользователь входит в систему, его пароль отправляется в открытом виде на сервер, который проверяет его по сохраненному хешу.
]Сейчас. Меня беспокоит то, что я посылаю пароль на сервер в открытом виде, и я продолжаю думать, что не буду очень доволен, если приложение, которое я использовал, сделало это с моим (use-for- все-вроде), но шифрование его на клиенте не принесет мне ничего особенного, поскольку злоумышленники могут просто использовать хешированный пароль, как если бы он был открытым.
Я гуглил все день для этого, и кажется, что Интернет довольно единодушен, когда дело доходит до этого - по-видимому, нечего получить от шифрования пароля на стороне клиента. Это , , это и , это - это всего лишь несколько примеров обсуждений и страниц, на которые я зашел, но есть много, еще много, все говорят, что То же самое.
Этот вопрос, в свете всего этого, может показаться немного ненужным, но я надеюсь, что где-то у кого-то будет другой ответ для меня.
Что я могу сделать, если ssl не вариант в этот момент , чтобы облегчить мои мысли об этом? Есть ли что-то, что нужно сделать, или реализация какой-либо схемы client-encrypt-server-decrypt-просто будет занимать много времени и бесполезна?
2 ответа
Для входа в систему SSL должен быть вашим вариантом, даже на этом этапе. Если это только для входа в систему, вам не нужна дорогая ферма SSL, но, по крайней мере, вы защищаете пароль (используемый для всех видов), даже если ясно, что оставшаяся связь не защищена []. *]. Это может означать, что вам нужно купить сертификат только для одного сервера входа, что опять же может сэкономить вам много денег, в зависимости от поставщика сертификата.
Для GWT: если вы не можете позволить себе шифровать все сообщения, вам придется разместить логин на отдельной странице из-за ограничений политики единого источника.
Если это все еще не вариант, вы можете подумать о входе в систему через OpenID, как это делает stackoverflow.
Не может быть какой-либо безопасной связи через незащищенные носители без некоторого предварительно общего секрета – обычно предоставляемого корневыми сертификатами, установленными в браузере (кстати, это забавно /страшно, что браузеры и даже целые операционные системы обычно загружаются через HTTP). Другие системы, например. PGP полагаются на ранее установленное доверие к "Сети доверия", но это всего лишь еще одна форма предварительно разделенных секретов. Нет никакого способа обойти это.
[*] Использование SSL для всего, к сожалению, сопряжено с дополнительными практическими проблемами: 1) страницы загружаются намного медленнее, особенно если на странице много элементов. Это происходит из-за вызванных SSL циклов обмена данными и возникающей в результате задержки, с которой вы не можете справиться даже с самой быстрой SSL-фермой. Проблема смягчается, но не полностью устраняется поддерживающими соединениями. 2) Если ваша страница содержит элементы с иностранных, не-HTTPS-сайтов (например, изображения, вставленные пользователями), многие браузеры будут отображать предупреждения, которые очень расплывчато о реальной проблеме безопасности и поэтому обычно неприемлемы для защищенного сайта.
Несколько дополнительных соображений (не рекомендация).
Давайте на мгновение предположим наихудший случай, то есть вы вообще не можете использовать SSL.В этом случае, как ни странно, хеширование пароля (с солью) перед его передачей может быть немного лучше, чем ничего не делать. Вот причина: он не может победить Мэллори (в криптографии, человека, который может манипулировать коммуникацией), но, по крайней мере, он не позволит Еве (человеку, который может только слушать) прочитать открытый текстовый пароль. Это может чего-то стоить, если предположить, что Евы более распространены, чем Мэллори (?). Но обратите внимание, что в этом случае вы должны хешировать пароль снова (с другой солью), прежде чем сравнивать его с значение базы данных.
Если SSL не вариант, то вы, очевидно, недостаточно заботитесь о безопасности ;)
А если серьезно, как вы упомянули, шифрование пароля на стороне клиента не очень хорошая идея. На самом деле, это очень плохо. Вы не можете доверять клиентской стороне для джека - что, если злоумышленнику удастся изменить код JS (через XSS или когда он был отправлен по сети), так что ваша MD5 / любая хеш-функция просто пройдет проход в открытом виде? Не говоря уже о том, что вы должны использовать хороший, надежный, защищенный метод шифрования, такой как bCrypt — что-то, что работает медленно на клиенте и, как упоминалось ранее, не совсем повышает безопасность приложения.
Вы могли бы попытаться обойти некоторые из этих проблем: отправив хеш-библиотеку каким-нибудь безопасным способом (если бы это было возможно, нам не пришлось бы сейчас со всем этим возиться, не так ли?), каким-то образом совместное использование общего секрета между сервером и клиентом и использование его для шифрования... но суть такова: используйте HTTPS, когда это возможно (в GWT трудно смешивать HTTPS и HTTP) и justified (если пользователь достаточно глуп, чтобы использовать один и тот же пароль для вашего приложения, не связанного с безопасностью, и для своего банковского счета, то весьма вероятно, что он использовал тот же пароль на ряде других сайтов, любой из которых может привести к перехвату пароля). Другие средства просто заставят вас думать, что ваше приложение более безопасно, чем оно есть на самом деле, и сделают вас менее бдительными.