Почему OWASP не рекомендует шифровать пароль как на клиенте, так и на сервере?

Question

Со времени недавних проблем с GitHub и Twitter:

• GitHub случайно записал некоторые незашифрованные пароли во внутренние журналы
• Twitter допускает запись открытого текстаПароли во внутренних журналах, как и в GitHub

Мне было интересно, почему не лучшая практика для шифрования пароля как на клиенте, так и на сервере?Поскольку я не буду менять ничего, что уже является наилучшей практикой для серверной стороны (соль, сильный хэш, HTTPS), это может быть только безопаснее.Сервер будет рассматривать уже хешированный пароль как пароль и будет хэшировать его снова перед сохранением.

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

Answer 1

Я пытался решить аналогичную проблему, когда на сервере можно было записать простой текстовый пароль.Вывод таков: вы всегда должны дополнительно хэшировать пароль клиента , если можете.

Вот несколько статей о клиент-плюс-сервер хэширование:

Хэширование пароля Client-Plus-Server как потенциальный способ повышения безопасности от атак методом перебора без перегрузки сервера

Хеширование с посоленными паролями - все правильно

В частности, см .:

В веб-приложении всегда хэш на сервере

Если вы пишете веб-приложение, вы можете задаться вопросомгде хешироватьНужно ли хешировать пароль в браузере пользователя с помощью JavaScript или его следует отправлять на сервер «в открытом виде» и хэшировать там?

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

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

Это не означает, что выне должен хешироваться в браузере, но если вы делаете, то вам абсолютно необходимо хешировать и на сервере.Хеширование в браузере , безусловно, является хорошей идеей, но учтите следующие моменты для вашей реализации:

Хеширование пароля на стороне клиента не заменяетHTTPS (SSL / TLS).Если соединение между браузером и сервером небезопасно, посредник может изменить код JavaScript по мере его загрузки, чтобы удалить функцию хеширования и получить пароль пользователя.

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

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

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

Единственно возможныйНедостатком является производительность клиента и проверка пароля на стороне сервера.Пользователь может манипулировать вашим клиентом JS и ввести «слабый» пароль.Сервер не знал бы лучше.Но я думаю, что это небольшая проблема, и она полагается на то, что люди намеренно изменяют свой клиентский код, чтобы ослабить собственную безопасность.

Answer 2

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

У Боба есть список (одиночное хеширование)пароли из журналов вашего сервера.Это не незашифрованные пароли, но они не являются паролями двойного хеширования из вашего файла паролей.Но, скажем, он вносит одно небольшое изменение в ваш клиент: он убирает строку bcrypt (), поэтому он больше не хэширует все, что он вставляет в поле пароля перед отправкой: вместо этого он просто отправляет необработанный текст.

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

Answer 3

Хэширование на стороне клиента может быть выполнено, но мы должны подумать о том, чего мы действительно достигаем.

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

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

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

Короче говоря, обычно это не стоит хлопот, преимущество слишком мало, а время лучше потратить на хеширование на сервере.

Answer 4

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

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

Итак, если вы не можете гарантировать, что все ваши пользователи работают на достаточно сильных устройствах, не рекомендуется делать bcrypt на стороне клиента.