Является GUID хорошей солью? мой процесс регистрации/входа в систему получил какой-то недостаток?

Если моя таблица внутри базы данных выглядит следующим образом:

 userid uniqueidentifier
 username varchar(20)
 password varbinary(max)

Когда пользователь отправляет (для регистрации), я отправляю пользователя/пароль в хранимую процедуру.

Хранимая процедура создает новый GUID (используя NEWID()), то я использую HashBytes (sha1) функции SQL Server для создания пароля на основе пароля GUID +, после чего я вставляю значения в таблицу выше.

Когда пользователь отправляет (для входа в систему), я отправляю пользователя/пароль в хранимую процедуру.

Хранимая процедура ищет имя пользователя и захватывает идентификатор пользователя для сравнения хэш-байта (sha1) пароля guid + с полем пароля.

Вы видите недостаток внутри этой логики?

Ответ 1

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

Ответ 2

Если безопасность является основной задачей, я предпочел бы НЕ использовать GUID для значения соли.

GUID имеет разные "типы", причем некоторые из них более "случайны", чем другие. Однако даже лучший тип GUID (это будет GUID типа V4 с точки зрения "случайности" ) не, который действительно подходит для криптографических функций.

Из Статья в Википедии о GUID:

V4 GUID используют более поздний алгоритм, который является псевдослучайным числом. Эти имеют "4" в том же положении, для пример {38a52be4-9352-453e-af97-5c3b448652f0}. Более конкретно, бит 'data3' шаблон будет 0001xxxxxxxxxxxx в первый случай, и 0100xxxxxxxxxxxx В секунду. Криптоанализ Генератор GUID WinAPI показывает, что, поскольку последовательность VID GUID псевдослучайным, учитывая начальное состояние можно прогнозировать до следующих 250 000 GUID, возвращаемые функцией UuidCreate. Вот почему GUID не должны использоваться в криптографии, например. g., как случайные ключи.

Ответ 3

Как описано, неясно, как работает механизм - я предполагаю, что поле userid содержит сгенерированный GUID (в противном случае я не вижу, как вы его извлекаете для сравнения).

Существуют различные типы GUID, причем не все из них случайны. Но тогда, случайность не требуется для вскрытия пароля. В целом, ваш подход выглядит отлично, хотя вы можете рассмотреть возможность выполнения хэширования несколько раз (укрепление ключа) для дальнейшего улучшения безопасности.

Ответ 4

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

Ответ 5

Почему вы заново изобретаете логин, когда не понимаете nonces?

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

Обновление, основанное на новых деталях вопроса из комментариев. Для приложения Windows GUI, использующего SQL Server, мои варианты проверки подлинности начинаются с:

Аутентификация домена (простая, но требующая домены).
Плакат. Не сложно, очень гибко, но требует клиентской инфраструктуры.
Проверка подлинности в смешанном режиме SQL Server (простая, но негибкая).
Kerberos через SSPI (сложнее, но очень настраиваемый).