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