2009-04-25 4 views
1

Я проверяю имя пользователя и пароль для входа в процедуру в MS SQL SERVER 2005. Поскольку SQL Server 2005 нечувствителен к регистру, даже если пользователь вводит строчный пароль вместо верхнего регистра , система позволяет войти в систему.MS SQL Server 2005 - проблема с нечувствительностью к регистру

Что мне делать? Есть ли какая-либо команда в Sql Server 2005, которая может проверить то же самое?

ответ

0

SQL Server 2005 - это только сопоставление по умолчанию, использующее нечувствительные к регистру сравнения. Вы не должны хранить пароли в виде открытого текста. Вы должны использовать их с достаточно надежным алгоритмом хеширования и хранить хэш. (возможно, вам действительно нужно использовать значение соли, но давайте начнем с хэширования).

3

Использовать чувствительную к регистру сортировку - например,

...where Password = @password COLLATE SQL_Latin1_General_CP1_CS_AS 

и да, вы не должны хранить пароли открытого текста в базе данных!

1

НИКОГДА НИКОГДА НИКОГДА НЕ БЫЛО хранить текстовые пароли! Сохраните хэш пароля и сравните это. Вы можете использовать функцию HashBytes().

+0

И согласно HTTP: //security.stackexchange .com/q/963/485, больше не используйте MD5. –

+1

@Rory - Я бы никогда не предложил md5-- HashBytes() поддерживает пару вариантов sha. Но это все еще старое - оно не поддерживает bcrypt, и если вы не используете bcrypt, вы делаете это неправильно. –

+0

Да - это v. Старый. Я думал, что этот ответ был с апреля '10, не в апреле 2009 года. bcrypt полностью :-) –

0

Используйте регистрозависимого collation для сравнения, например:

SELECT 
    Id 
FROM 
    UserTable 
WHERE 
    UserName = @UserName 
    AND Password = @Password COLLATE SQL_Latin1_General_Cp1_CS_AS 

Используйте параметры сортировки, соответствующий набор символов столбца паролей.

Одно другое примечание - вы уверены, что хотите сохранить в текстовом поле в текстовом поле? Это хорошо в Top 5 of the Don'ts, когда речь идет о решениях безопасности.

+0

можете усовершенствовать это? – Roshan

-2

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

Помимо установки сортировки, вы можете также использовать VARBINARY трюк как так:

WHERE 
    CAST(Password as varbinary(20)) = CAST(@Password as varbinary(20)) AND 
    CAST(Username as varbinary(20)) = CAST(@Username as varbinary(20)) 

выше будет также привести в случае чувствительного поиска - просто помните, чтобы установить длину VARBINARY к тому же, как поле длины.

Чтобы избежать индекса сканирования, вы можете включить поиск без учета регистра, а также - что сделает индекс поиска и впоследствии выполнить поиск VARBINARY:

WHERE 
    Password = @Password AND 
    Username = @Username AND 
    CAST(Password as varbinary(20)) = CAST(@Password as varbinary(20)) AND 
    CAST(Username as varbinary(20)) = CAST(@Username as varbinary(20)) 
+0

Можете ли вы привести пример, когда это действительно так, чтобы сохранить пароль как чистый текст? Это должно быть в системе, которую я никогда не буду использовать, поскольку не может быть допустимого примера, где я хочу, чтобы вы знали мой пароль. –

+0

Взаимодействие с устаревшими системами, например. Все, о чем я говорю, это то, что могут быть причины, по которым один хочет хранить cleartext вместо того, чтобы хэшировать его, - и я действительно не вижу причин для 10 ответов, в которых говорится о том же совете, не предлагая прямого решения для того, что спрашивает OP. –

Смежные вопросы