On 8/2/06, Øyvind Harboe <[EMAIL PROTECTED]> wrote:
> Another possiblity is to use likeIgnoreCaseExp to pull in results, but
> then go in and manually filter out anything that's not an exact match
> in your code.   That's probably the safest bet and the most portable.
>  Of course, you then have to deal with the possiblity that someone's
> password is "%"

After good nights sleep I arrived at the same conclusion. I pass the
umodified password to likeIgnoreCaseExp and then I do a String compare
against the password in the *first* record that matched.

I don't care about the case where escape chars used in passwords would
cause likeIgnoreCaseExp to not include the record in the query result.

The only thing I assume here is that it is safe to pass a string from
an attacker to likeIgnoreCaseExp().

I don't see any security issues.    The issue I see is that you may
get back every single record if their password is the wild card
symbol.

Again, if it were me, and I was knowledgable about the specific
database being used, I'd try to go through and first replace all
"match everything" wildcard symbols with "match one" wildcard symbols
to decrease the amount of returned results.

Ie, for Oracle, if the password specified is "this%one", I would
change the string to "this_one" before calling likeIgnoreCase.

I don't understand your comment about comparing against only the first
result.   You'd have to compare until you found a match or until you
were sure that nothing matched.

Do you have only a password or also a username?   A username/password
combination match would be far better as you'd likely get far less
matches.

Not sure about the possiblity of an escape character making a match
impossible, but it sounds like you don't care.

Reply via email to