Case Sensitive SQL

[vunet.us]

So, I came across the problem every developer comes across with once:
case in SQL. My users login with their selected user name and when SQL
checks for user name value, case is ignored. For example, user1 is
equal to User1. This causes some problems in cases where I validate
user names for authentication to access some secure files. Anyway,
what can I do to make sure User1 cannot log in if database stores
user1?
Suggestions are very appreciated.
Thanks.

 

[daddywhite]

So, I came across the problem every developer comes across with once:
case in SQL. My users login with their selected user name and when SQL
checks for user name value, case is ignored. For example, user1 is
equal to User1. This causes some problems in cases where I validate
user names for authentication to access some secure files. Anyway,
what can I do to make sure User1 cannot log in if database stores
user1?
Suggestions are very appreciated.
Thanks.

This should solve all your problems:

http://sqlserver2000.databases.aspfaq.com/how-can-i-make-my-sql-queries-case-sensitive.html

 

[Bob Barrows [MVP]]

So, I came across the problem every developer comes across with once:
case in SQL. My users login with their selected user name and when SQL
checks for user name value, case is ignored. For example, user1 is
equal to User1. This causes some problems in cases where I validate
user names for authentication to access some secure files. Anyway,
what can I do to make sure User1 cannot log in if database stores
user1?
Suggestions are very appreciated.
Thanks.

Are you talking about SQL Server? What version? Are you aware that you can
change to a case-sensitive collation? Depending on the version you can do
this at the column level.

 

[Evertjan.]

wrote on 17 aug 2007 in microsoft.public.inetserver.asp.general:

So, I came across the problem every developer comes across with once:
case in SQL. My users login with their selected user name and when SQL
checks for user name value, case is ignored. For example, user1 is
equal to User1. This causes some problems in cases where I validate
user names for authentication to access some secure files. Anyway,
what can I do to make sure User1 cannot log in if database stores
user1?

You don't.

When searching for the right unique record, you should choose for case
insensitivity, as the user is not to be trusted with case sensetive
usernames and the sql WHERE clause is case insensitive [in most engines].

Subsequent vbs testing of the password with:

if fields("password") = request.form("password") then

is case sensitive unless you do

if ucase(fields("password")) = ucase(request.form("password")) then

 

[vunet.us]

wrote on 17 aug 2007 in microsoft.public.inetserver.asp.general:

So, I came across the problem every developer comes across with once:
case in SQL. My users login with their selected user name and when SQL
checks for user name value, case is ignored. For example, user1 is
equal to User1. This causes some problems in cases where I validate
user names for authentication to access some secure files. Anyway,
what can I do to make sure User1 cannot log in if database stores
user1?

You don't.

When searching for the right unique record, you should choose for case
insensitivity, as the user is not to be trusted with case sensetive
usernames and the sql WHERE clause is case insensitive [in most engines].

Subsequent vbs testing of the password with:

if fields("password") = request.form("password") then

is case sensitive unless you do

if ucase(fields("password")) = ucase(request.form("password")) then

I like this solution: if fields("password") = request.form("password")
then...
I use SQL Server but with no full control as it is a hosting package.
I am afraid I won't be able to set columns to be case-sensitive even
if this could be a good solution.
But so far I stick with the solution above (which I thought of before
but wasn't sure...).
Thank you.

 

[Evertjan.]

wrote on 17 aug 2007 in microsoft.public.inetserver.asp.general:

wrote on 17 aug 2007 in microsoft.public.inetserver.asp.general:

So, I came across the problem every developer comes across with
once: case in SQL. My users login with their selected user name and
when SQL checks for user name value, case is ignored. For example,
user1 is equal to User1. This causes some problems in cases where I
validate user names for authentication to access some secure files.
Anyway, what can I do to make sure User1 cannot log in if database
stores user1?

You don't.

When searching for the right unique record, you should choose for
case insensitivity, as the user is not to be trusted with case
sensetive usernames and the sql WHERE clause is case insensitive [in
most engines].

Subsequent vbs testing of the password with:

if fields("password") = request.form("password") then

is case sensitive unless you do

if ucase(fields("password")) = ucase(request.form("password")) then

I like this solution: if fields("password") = request.form("password")
then...
I use SQL Server but with no full control as it is a hosting package.
I am afraid I won't be able to set columns to be case-sensitive even
if this could be a good solution.
But so far I stick with the solution above (which I thought of before
but wasn't sure...).
Thank you.

You could also vbs test the same way if the username, found
caseINsensitively by WHERE, is still a match casesenitively,
but I would advice against that for the above reasons and because the
preset uniqueness of the username field in the database would perhaps be
in question.

 

[Mark J. McGinty]

This should solve all your problems:

http://sqlserver2000.databases.aspfaq.com/how-can-i-make-my-sql-queries-case-sensitive.html

Or, alternatively:

------------------

CREATE TABLE #users (
[id] int identity(1,1) not null,
[login] varchar(50) not null,
[pwd] varchar(50) not null
)
Declare @login varchar(50), @pwd varchar(50)
SET NOCOUNT ON
INSERT INTO #users ([login], [pwd])
VALUES ('mm', 'aBcDeFGhh')

Set @login = 'mm'
Set @pwd = 'aBcDeFGhh'

SELECT * FROM #users
WHERE ([login] = @login) AND ([pwd] = @pwd)
AND (BINARY_CHECKSUM([login]) = BINARY_CHECKSUM(@login))
AND (BINARY_CHECKSUM([pwd]) = BINARY_CHECKSUM(@pwd))

DROP TABLE #users

 

[Bob Barrows [MVP]]

SELECT * FROM #users
WHERE ([login] = @login) AND ([pwd] = @pwd)
AND (BINARY_CHECKSUM([login]) = BINARY_CHECKSUM(@login))
AND (BINARY_CHECKSUM([pwd]) = BINARY_CHECKSUM(@pwd))

DROP TABLE #users

Right, but that of course disallows the use of any indexes on those columns
.... which of course may not be a problem on a sufficiently small number of
rows.

 

[Mark J. McGinty]

SELECT * FROM #users
WHERE ([login] = @login) AND ([pwd] = @pwd)
AND (BINARY_CHECKSUM([login]) = BINARY_CHECKSUM(@login))
AND (BINARY_CHECKSUM([pwd]) = BINARY_CHECKSUM(@pwd))

DROP TABLE #users

Right, but that of course disallows the use of any indexes on those
columns ... which of course may not be a problem on a sufficiently small
number of rows.

How so, they are still in the WHERE predicate? The case-insensitive
comparison is still required, otherwise character transpositions would
compare as equal...

I created a composite index on both fields, here's the query plan:

|--Index Seek(OBJECT[misc].[dbo].[logintest].[IX_logintest]),
SEEK[logintest].[login]=[@login] AND [logintest].[pwd]=[@pwd]),
WHEREbinary_checksum([logintest].[login])=binary_checksum([@login])
AND binary_checksum([logintest].[pwd])=binary_checksum([@pwd]))
ORDERED FORWARD)

What's more, binary_checksum is deterministic, so indexable computed columns
for the checksum values could be created. In fact, a single checksum
computed for both would be just as good, and slightly more efficient:

SELECT * FROM #users
WHERE ([login] = @login) AND ([pwd] = @pwd)
AND (BINARY_CHECKSUM([login], [pwd]) = BINARY_CHECKSUM(@login, @pwd))


Of course, none of this approaches the bummers of storing passwords in plain
text. If the OP stored a hash of the password instead of its text, the case
sensitivity issue becomes entirely moot.


-Mark

 

[Bob Barrows [MVP]]

SELECT * FROM #users
WHERE ([login] = @login) AND ([pwd] = @pwd)
AND (BINARY_CHECKSUM([login]) = BINARY_CHECKSUM(@login))
AND (BINARY_CHECKSUM([pwd]) = BINARY_CHECKSUM(@pwd))

DROP TABLE #users

Right, but that of course disallows the use of any indexes on those
columns ... which of course may not be a problem on a sufficiently
small number of rows.

How so, they are still in the WHERE predicate?

You're right. My eyes skimmed over this part: "([login] = @login) AND ([pwd]
= @pwd)"
That part allows the index to be used.