Хеширование / посол на стороне клиента через HTTPS

Question

Мне интересно, какие серьезные проблемы возникают при следующей настройке:

Имя пользователя / пароль, схема входа Javascript / ajax запрашивает солт-значение с сервера (мы установили в предыдущих вопросах, соль не является секретным значением) Javascript предварительно формирует SHA1 (или иным образом) пароля и соли. Javascript / Ajax возвращает хэш на сервер Сервер применяет другую соль / хеш поверх той, что была отправлена ​​через ajax.

Транзакции выполняются по протоколу HTTPS.

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

Answer 1

Как всегда: будьте очень осторожны при разработке криптографических протоколов самостоятельно.

Но, как говорится, я вижу преимущество в схеме. Он будет защищать от пароля, раскрываемого при атаке "человек посередине", и будет гарантировать, что сервер никогда не увидит действительный пароль, предотвращая некоторые внутренние атаки. С другой стороны, он не защищает от ловли человека в браузере, рыбалки и т. Д.

Возможно, вы захотите прочитать RFC 2617 об аутентификации доступа к дайджесту HTTP. Эта схема похожа на то, что вы предлагаете.

Answer 2

Все эти усилия по передаче солей и хэшей между клиентом и сервером уже встроены в базовый протокол HTTPS / SSL.Я был бы очень удивлен, если уровень безопасности в javascript очень сильно поможет.Я рекомендую держать это простым и использовать открытый текст поверх SSL на стороне клиента.Беспокойство по поводу шифрования на стороне сервера.

Answer 3

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

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

Answer 4

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

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

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

Answer 5

Вы ничего не получаете.Нет никакого смысла, если Joe Public может увидеть это, нажав View> Source, и старый принцип о том, что никогда нельзя доверять вводу клиента, удваивается для хеширования пароля.

Если вы действительно хотите повысить безопасность, используйте SHAХэш на основе -2 (SHA-224/256/384/512), так как SHA-1 имеет потенциальные уязвимости.NIST больше не рекомендует SHA-1 для приложений, уязвимых к атакам коллизий (например, хэши паролей).