tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Authenticating Users
Date Mon, 23 Feb 2009 03:06:50 GMT
Hash: SHA1



On 2/22/2009 8:52 PM, Martin Gainty wrote:
>> Alan Chaney wrote:
>> To summarize
>> 1. password be case insensitive [I may be able to talk them out of this]
> MG>handled from java.lang.String toUpperCase/toUpperCase

He's trying to do a case-insensitive match in the database. Do you
suggest executing "SELECT * FROM user" and then uppercasing every
username looking for the right one? It's already been pointed out that
many databases already perform case-insensitive CHAR/VARCHAR matching
/and/ that not all databases have the same functions for performing this
on the server-side (which is the only reasonable place to do it).

>> 2. username be case insensitive.
> MG>leave as case-sensitive

What's the matter... you don't like the requirements?

>> 3. email address can be used as a synonym for the user name.
> MG>store email as a column in your users table

Er... he's already got that. Have you been reading?

>> 4. Security managed by Tomcat CMS.
> MG>use Realm as earlier suggested storing user and role info in users and user_roles
> MG>respectively

He's already doing that.

>> Mark T suggested that I modify DSR appropriately.
> MG>DSR is ready for deployment just match your tablenames for users and user_roles
> MG>also match your userNameCol and userCredCol and roleNameCol

Not true... he wants to use /either/ username /or/ email address as the
user identifier.

>> Chris Schultz pointed out correctly that it gets a bit more complicated 
>> if the pwd must be hashed.
> MG>no harm stick into Oracle DB as a Blob column (binary large object) or as RAW

Why would you bother doing that? The digester already provides the
hashed password as a string, so putting it into a CHAR field makes more

>> I've looked at the code to DSR and it seems to me that the following 
>> would work.
>> 1. add an 'alternative' userNameCol (eg altNameCol) and in the 
>> configuration as above point that at the email column.
> MG>good..
>> 2. in the code, IF the login fails using the 'user_name' then try it 
>> with the altNameCol.
> MG>the result from action class will path you there ..but you're on the right track..


>> Defaults could be chosen such that the current configuration setup still 
>> works (eg the default value for isCaseInsensitive is false)
> MG>sensitive stuff like username/password goes in DB
> MG>everything else to get the page up and running can go into a flat file(.properties/stylesheets)

Okay, my brain is hurting. What are you talking about?

>> Only real gotcha that I can see for making it database independent is 
>> that the function used to create lower case is not univerally 'lower()' 
>> (M/SQL appears to be toLower()) so it might be necessary to pass the 
>> string for the function name as an optional configuration parameter.
> MG>I've been working with Oracle recently MySQL last year and Oracle is case-sensitive
> MG>oracle!=ORACLE but MySQL will take upper/lower or camelcase queriesfor same result

If you mean that MySQL performs CHAR and VARCHAR comparisons without
regard to case then yes, this is true. You can get case-sensitive
matches by casting one of the operands to BINARY CHAR/VARCHAR.

>> I realize that many people would advise against the idea of case 
>> insensitive passwords - however, despite my personal reservations I am 
>> willing to accept that in the case of this particular application the 
>> reduction in security is acceptable.
> MG>decide on uppercase or lowercase and stick to it..
>> If hashed pwds are used then there are 3 solutions:
>> 1. don't allow case insensitive passwords - only user names.
> MG>UserNames should be case sensitive AL != al (at least in Oracle)

Dude. Read. The. Requirements. Nobody cares how you think things should
be. This is a business requirement. You can't simply say "no".

>> 2. provide two columns one for lower case versions of the pwd.
> MG>not a good idea and violates data normalisation one copy in DB 
> MG>use uppercase or lower case only for view

Two different passwords in the database is not denormalization.

Whenever we change password strategies (it's happened twice), we store
the old-style password in one column and the new-style password in
another. After a while (usually like a year or more), we phase-out the
old-style and suspend the logins of all the users who haven't "upgraded"
their passwords. I think this is a perfectly reasonable strategy.

>> 3. convert all the existing password HASHES to the lower case equivalent,
> MG>wont work A (0x41) != a(0x61) can assume tolower is a simple addition of
hex 20
> MG>when the hash algo gets ahold of the character the 0x41 hashes differently than

This is a bad assumption as it only works with US-ASCII. This is not
even true for the simple Latin charsets that are included in ISO-8859-1.

He's talking about using a lowercase version of all passwords to
generate hashes. These new-style hashes will be stored in the new-style
column in the dat...

Oh, forget it. We all know what's going on.

- -chris
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message