Клиентская побочная хеширование / солование через HTTPS

Question

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

Имя пользователя / Пароль Схема входа в систему JavaScript / Ajax Запросывает значение соли с сервера (мы установили в предыдущих вопросах соли не является секретной ценностью) JavaScript Preforms SHA1 (или иным образом) пароля и соли. JavaScript / Ajax Возвращает хеш на сервер, который сервер применяет еще одну соль / хеш в верхней части, которую отправляется через AJAX.

Транзакции превышают HTTPS.

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

Ты ничего не набираешь. Нет смысла к соли, если Joe Public может видеть его, нажав кнопку «Вид»> «Источник», а старый максим «Никогда не доверяющий клиентский ввод» идет двойной для перемешивания паролей.

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

Answer 5

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

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

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