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

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

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

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

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

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

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

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

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

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

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

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