Я не имею в виду создание хэша на стороне клиента и последующее его непосредственное сохранение в базе данных. Я нашел несколько вопросов с похожей темой, но большинство этих ответов предполагали сценарий, в котором пароли отправлялись через незашифрованные соединения или хэш клиента хранился непосредственно в базе данных.
(1) Сценарий, который я описываю, является дополнительным шагом поверх существующих рабочих процессов, когда пользователь отправляет открытый текст через https-соединение, а сервер хэширует его с солью и сохраняет хэш и соль в базе данных. Итак, вместо отправки фактического пароля, что, если хэш вычисляется на стороне клиента и отправляется на сервер. Для всех намерений и целей сервер затем рассматривает этот первоначальный хэш клиента как пароль пользователя в виде открытого текста, а затем повторно хэширует с солью, используя свой собственный метод хеширования, как это обычно делается. В случае, когда сервер случайно регистрирует введенный пользователем пароль (например, во время отладки), фактический пароль все равно будет безопасным.
(2) Кроме того, если хеширование на стороне клиента не является плохой практикой безопасности, как насчет добавления общей строки, уникальной для приложения (например, доменного имени приложения) или уникальной строки (например, имени пользователя) к паролю пользователя перед хешированием, чтобы гарантировать, что хэш клиента для того же пароля будет отличаться от аналогичного хэша, сгенерированного другим приложением. Имеет ли значение положение такой строки (добавлено или добавлено).
Одна проблема, о которой я могу думать, заключается в том, что сервер не сможет навязать пользователям определенную сложность пароля. Пользователи по-прежнему могут быть предупреждены (или пароли могут быть отклонены) на стороне клиента, но пользователь по-прежнему может обойти его и отправить любую строку той же длины, что и ожидаемая длина хэша.
