RE: Authenticating Users
This is what I did for our JDBC realmforced uppercase with javascript on the alphan-numeric user id. Then the password was whatever they made it, even though it was case sensitive. Trying to figure out what the good of making passwords case-insensitive would be. Purpose-defeating at best it seems. -Original Message- From: Gregor Schneider [mailto:rc4...@googlemail.com] Sent: Sunday, February 22, 2009 3:12 PM To: Tomcat Users List Subject: Re: Authenticating Users To the OP: 1. May I ask what database it is you're using? 2- I'd go for the following solution: Create a JSP-page accepting the credentials. The username should be converted to uppercase. The password should be left as is so that case-sensivity here is maintained. Don't know if I'm missing something, but to me that looks like a walk in the park. Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Authenticating Users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin, Wow. 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 > http://java.sun.com/javase/6/docs/api/java/lang/String.html 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 tables > 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 sense. >> 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.. Huh? >> 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) ..you 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 0x61 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 usi
RE: Authenticating Users
> > Martin Gainty wrote: > > Which specific attributes are you seeking that are not in DataSourceRealm? > > >dataSourceName="jdbc/authority" > >userTable="users" userNameCol="user_name" userCredCol="user_pass" > >userRoleTable="user_roles" roleNameCol="role_name"/> > > http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#DataSourceRealm > > > > ? > > > To summarize > > I (or,actually my "marketing dept') have the following requirements. MG>yes I keep forgeting they're running the show these days > 1. password be case insensitive [I may be able to talk them out of this] MG>handled from java.lang.String toUpperCase/toUpperCase http://java.sun.com/javase/6/docs/api/java/lang/String.html > 2. username be case insensitive. MG>leave as case-sensitive > 3. email address can be used as a synonym for the user name. MG>store email as a column in your users table > 4. Security managed by Tomcat CMS. MG>use Realm as earlier suggested storing user and role info in users and user_roles tables MG>respectively > > 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 > 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 > > 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.. > 3. to make things case insenstive simply convert the username to lower > case and use a 'lower' function on the column value. MG>store all strings as either uppercase or all lowercase your app may not be case-sensitive MG>but Databases are case-sensitive > 4. to make the thing a bit more flexible an additional boolean parameter > 'isCaseInsensitive' could be added to select the behavior has in 3. above. MG>make sure its case sensitive by the time it goes into the DB > 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) > 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 > 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) > 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 > 3. convert all the existing password HASHES to the lower case equivalent, MG>wont work A (0x41) != a(0x61) ..you 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 0x61 > but hashed passwords are not my principal concern > > I've downloaded and built 6.0.18 and looked at the DSR code - doesn't > look like a very big job to make the changes that I want so I may have > go tomorrow. As I use 6.0.18 I can easily test it by just patching in > the .class file for DataSourceRealm on my dev. system. MG>yes the DSR example is comprehensive and easy to follow MG>Keep us apprised on how you progress.. MG>Best > Regards MG>MG > Alan > > > > > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > _ It’s the same Hotmail®. If by “same” you mean up to 70% faster. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_AE_Same_022009
Re: Authenticating Users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan, On 2/22/2009 4:47 PM, Alan Chaney wrote: > From my point of view, as I don't use hashed passwords at the moment the > easiest thing to do is to modify the DataSourceRealm as suggested by > Mark Thomas. However, I think that the ability to extend the login > system to use either a user name or an email address would probably be > useful for other people. I think it might be easier than you think. Here's the code for DataSourceRealm's SQL query builder for the "credential selection" (TC 6.0.16): // Create the credentials PreparedStatement string temp = new StringBuffer("SELECT "); temp.append(userCredCol); temp.append(" FROM "); temp.append(userTable); temp.append(" WHERE "); temp.append(userNameCol); temp.append(" = ?"); preparedCredentials = temp.toString(); All you need to do is hack the start() method (which builds the SQL queries) plus the credentials() method and you should be good to go. You could create a relatively inelegant system of attributes that would build a more complex query, or you could just hack the realm and be done with it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmh/0gACgkQ9CaO5/Lv0PAYVQCgvDo9FpFQd4zxgmuG66zqNe1y MlUAn3MmLx8Bb4LScyhXPpfIspcCKygu =8PUl -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Authenticating Users
Martin Gainty wrote: Which specific attributes are you seeking that are not in DataSourceRealm? http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#DataSourceRealm ? To summarize I (or,actually my "marketing dept') have the following requirements. 1. password be case insensitive [I may be able to talk them out of this] 2. username be case insensitive. 3. email address can be used as a synonym for the user name. 4. Security managed by Tomcat CMS. Mark T suggested that I modify DSR appropriately. Chris Schultz pointed out correctly that it gets a bit more complicated if the pwd must be hashed. 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. 2. in the code, IF the login fails using the 'user_name' then try it with the altNameCol. 3. to make things case insenstive simply convert the username to lower case and use a 'lower' function on the column value. 4. to make the thing a bit more flexible an additional boolean parameter 'isCaseInsensitive' could be added to select the behavior has in 3. above. Defaults could be chosen such that the current configuration setup still works (eg the default value for isCaseInsensitive is false) 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. 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. If hashed pwds are used then there are 3 solutions: 1. don't allow case insensitive passwords - only user names. 2. provide two columns one for lower case versions of the pwd. 3. convert all the existing password HASHES to the lower case equivalent, but hashed passwords are not my principal concern I've downloaded and built 6.0.18 and looked at the DSR code - doesn't look like a very big job to make the changes that I want so I may have go tomorrow. As I use 6.0.18 I can easily test it by just patching in the .class file for DataSourceRealm on my dev. system. Regards Alan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Authenticating Users
Which specific attributes are you seeking that are not in DataSourceRealm? http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#DataSourceRealm ? Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. > Date: Sun, 22 Feb 2009 13:47:54 -0800 > From: a...@compulsivecreative.com > To: users@tomcat.apache.org > Subject: Re: Authenticating Users > > Gregor Schneider wrote: > > To the OP: > > > > 1. May I ask what database it is you're using? > > > Postgres - but a more general solution would be nice. > > 2- I'd go for the following solution: > > > > Create a JSP-page accepting the credentials. The username should be > > converted to uppercase. The password should be left as is so that > > case-sensivity here is maintained. > > > > That doesn't actually fit in with the Servlet CMS. I can easily decode > the user name and password by your mechanism. However, then I have to > rather extensively modify my code (covering 3 applications and 4 web > services) to apply the credentials. What I was looking for was a way of > extending what I already have. > > > Don't know if I'm missing something, but to me that looks like a walk > > in the park. > > > See above. The problem is not decoding the password, but making sure > that the container managed security mechanism is maintained. > > So far, the best suggestions that I've had are: > > 1. Modify DataSourceRealm > 2. Use secuirityfilter. > > From my point of view, as I don't use hashed passwords at the moment > the easiest thing to do is to modify the DataSourceRealm as suggested by > Mark Thomas. However, I think that the ability to extend the login > system to use either a user name or an email address would probably be > useful for other people. I'll give it some thought. > > Regards > > Alan > > > > > > > > > > > > > > > > > > Rgds > > > > Gregor > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > _ Windows Live™ Hotmail®…more than just e-mail. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_howitworks_022009
Re: Authenticating Users
Gregor Schneider wrote: To the OP: 1. May I ask what database it is you're using? Postgres - but a more general solution would be nice. 2- I'd go for the following solution: Create a JSP-page accepting the credentials. The username should be converted to uppercase. The password should be left as is so that case-sensivity here is maintained. That doesn't actually fit in with the Servlet CMS. I can easily decode the user name and password by your mechanism. However, then I have to rather extensively modify my code (covering 3 applications and 4 web services) to apply the credentials. What I was looking for was a way of extending what I already have. Don't know if I'm missing something, but to me that looks like a walk in the park. See above. The problem is not decoding the password, but making sure that the container managed security mechanism is maintained. So far, the best suggestions that I've had are: 1. Modify DataSourceRealm 2. Use secuirityfilter. From my point of view, as I don't use hashed passwords at the moment the easiest thing to do is to modify the DataSourceRealm as suggested by Mark Thomas. However, I think that the ability to extend the login system to use either a user name or an email address would probably be useful for other people. I'll give it some thought. Regards Alan Rgds Gregor - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Authenticating Users
(function() { var doLogin = function() { var uname = doc.byId("name").toLowerCase(); var passw = doc.byId("password").toLowerCase(); //var digest = sha1.digest(uname + ":My Realm:" + passw); xhr.send(...); } return { login: function() { doLogin(); return false; } } })(); ... all hidden and private handling of the user name and password. Might not work without javascript :) On Feb 22, 2009, at 4:11 PM, Gregor Schneider wrote: To the OP: 1. May I ask what database it is you're using? 2- I'd go for the following solution: Create a JSP-page accepting the credentials. The username should be converted to uppercase. The password should be left as is so that case-sensivity here is maintained. Don't know if I'm missing something, but to me that looks like a walk in the park. Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Authenticating Users
To the OP: 1. May I ask what database it is you're using? 2- I'd go for the following solution: Create a JSP-page accepting the credentials. The username should be converted to uppercase. The password should be left as is so that case-sensivity here is maintained. Don't know if I'm missing something, but to me that looks like a walk in the park. Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Authenticating Users
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, I was the OP on this one. Mark just made a couple of suggestions. On 2/21/2009 4:06 PM, Mark Thomas wrote: 5. Patch DataSourceRealm 6. Make case sensitivity configurable and contribute your patch back to the ASF. 7. Use securityfilter to write your realm, and not be tied to Tomcat. Had a brief look at 'securityfilter' - however we actually do require container managed security as we have several applications. Other alternative as previously mentioined is acegi. 8. Many databases use case-insensitive string comparisons already. Case-insensitive passwords (probably a bad idea!) Actually, in general, I agree that its a bad idea. However, each case has to be handled in the light of the actual users expectations. In the case of this specific application the users are artists who are generally extremely computer naive. We commonly get support enquiries "I can't log into my account" EVEN THOUGH we have sent them their account names and passwords because they are not correctly capitalizing their usernames or passwords. It is important to keep to keep the case of usernames because, as I said, they are artists, and the capitalization may have significance to them as part of their brand. The information on the site is publically available after it has been published. There is no commercial or sensitive information on the site. will work if you aren't hashing them. If you are, you'll have to lowercase them or something. Exactly. One problem for a general solution is that there are variations in the name of the 'lowercase' function between databases. So far, I've found that Postgres, MySQL and Oracle appear to support 'lower()' but M/SQL has it as tolower() (thanks again MS) If you /are/ hashing them, you'll need to do a password migration where anyone who changes their password gets it lowercased but passwords that existed beforehand are still case-sensitive. You cannot avoid this, now matter what your solution is. In this specific case at the moment we aren't hashing them, but you raise a good general point about hashing which I'll have to think about. Regards Alan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Authenticating Users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 2/21/2009 4:06 PM, Mark Thomas wrote: > 5. Patch DataSourceRealm > > 6. Make case sensitivity configurable and contribute your patch back to > the ASF. 7. Use securityfilter to write your realm, and not be tied to Tomcat. 8. Many databases use case-insensitive string comparisons already. Case-insensitive passwords (probably a bad idea!) will work if you aren't hashing them. If you are, you'll have to lowercase them or something. If you /are/ hashing them, you'll need to do a password migration where anyone who changes their password gets it lowercased but passwords that existed beforehand are still case-sensitive. You cannot avoid this, now matter what your solution is. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmhZ48ACgkQ9CaO5/Lv0PAlOACgrwTelHoTXc0nAbo0+D0rFhez G3YAnjh3JqHj/bLWvFY2vsFFRMTcd7oK =GYQE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Authenticating Users
Mark Thomas wrote: 5. Patch DataSourceRealm (should just be a couple of changes to make the checks case insensitive) and deploy your patched version to each of your Tomcat instances. To do this you'd put your DataSourceRealm.class file in CATALINA_HOME/lib/org/apache/catalina/realm 6. Make case sensitivity configurable and contribute your patch back to the ASF. Providing it is database neutral, there is a good chance it will be accepted for Tomcat 7 and maybe back-ported to Tomcat 6. Mark Ok Mark I'll have a go at 5. and 6. I'll report back in a few days. Regards Alan Chaney - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Authenticating Users
Alan Chaney wrote: > We have a site which has users log in to create/edit account > information. Nothing unusual there. Currently this is implemented with a > JDBCRealm and it all works OK. I'd base your solution on the DataSourceRealm. JDBCRealm is very heavily synchronised . > So far, I can see the following options: > > 1. Implement a filter that ... > > 2. Implement some java script ... > > 3. Implement my own Realm ... > > 4. Possibly do something similar to 3 but with a JAAS. 5. Patch DataSourceRealm (should just be a couple of changes to make the checks case insensitive) and deploy your patched version to each of your Tomcat instances. To do this you'd put your DataSourceRealm.class file in CATALINA_HOME/lib/org/apache/catalina/realm 6. Make case sensitivity configurable and contribute your patch back to the ASF. Providing it is database neutral, there is a good chance it will be accepted for Tomcat 7 and maybe back-ported to Tomcat 6. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org