tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Abernethy IV" <aberne...@dynedge.com>
Subject Fw: Re: JDBCRealm
Date Tue, 21 Jan 2003 07:10:58 GMT
Is there a way to tell Tomcat to use a 'salt' when generating the MD5 digest 
for JDBCRealm authentication?  If not, I think this is a feature that should 
be added in the future.  For example,

<Realm className="org.apache.catalina.realm.JDBCRealm"
       ...
       userTable="pg_shadow"
       userNameCol="usename"
       userCredCol="passwd"
       digest="MD5"
       salt="usename" />

--
Robert Abernethy IV
Dynamic Edge, Inc.
734.975.0460


---------- Forwarded Message -----------
From: "Rob Abernethy IV" <abernethy@dynedge.com>
To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Sent: Sun, 12 Jan 2003 14:30:22 +0800
Subject: Re: JDBCRealm

Alright, I finally have my answer.  Postgres prepends the username to the 
password before creating the digest.  For example, if I wish to create a 
postgres account with the username 'tomcat' and password 'tomcat', postgres 
will prepend 'tomcat' to 'tomcat' to create 'tomcattomcat' and then make the 
digest.  Unfortunately, I don't think there is any way to tell postgres 
*not* to use a salt when creating the encrypted version of the password.

--
Robert Abernethy IV
Dynamic Edge, Inc.
734.975.0460

> Ok, I got Java and Perl to come up with the same digest.  Postgres' 
> is different.  I think it has something to do with the 'salt'. 
>  Postgres uses the username as salt.  I don't know much about MD5 
> encryption, but it seems as though Java is using a different salt 
> and, therefore, coming up with a different digest.
> 
> --
> Robert Abernethy IV
> Dynamic Edge, Inc.
> 734.975.0460
> 
> > Clear-text password: tomcat
> >
> > java org.apache.catalina.RealmBase -a MD5 tomcat
> > 1b359d8753858b55befa0441067aaed3
> >
> > select passwd from pg_shadow where usename='tomcat'
> > md5efcc1c51a80be13b59cdb96d758a0184
> >
> > md5sum -t < tomcat
> > 042d39e062dd4bf342e088dc832526f9
> >
> > String password = "tomcat";
> > byte[] md_password = password.getBytes();
> > MessageDigest md = MessageDigest.getInstance("MD5");
> > byte[] md_hash = md.digest(md_password);
> > System.out.println(md_hash);
> > [B@15f5897
> >
> > So obviously the authentication is failing because the MD5'd
> > passwords don't match.  Tomcat is calculating the digest using the
> > RealmBase and the digest stored in the table was created by
> > Postgres.  Is there a reason why these are all different?
> >
> > --
> > Robert Abernethy IV
> > Dynamic Edge, Inc.
> > 734.975.0460
> >
> > > ----- Original Message -----
> > >
> > > > The MD5'd password *is* in the pg_shadow.passwd column.  I don't see
> what
> > > > I'm doing wrong.
> > >
> > > Is Postgres (or anything other than Java) generating the MD5'd
> > > passwords for the pg_shadow table?  If so, have you manually
> > > generated the MD5's to see if they are the same?
> > >
> > > Even if they are you can run into problems with storage formats.  If
> > > Postgres is using a different char set than the Java JVM for 
manipulating
> > > the strings, you can have mismatches.
> > >
> > > Also, if you use CHAR instead of  VARCHAR you may have extra spaces
> > > stuck on the end of the returned string to pad it out.
> > >
> > > The MD5 is longer than the string it is generated from so you need
> > > to make sure you have plenty of room for it.
> > >
> > > For example if Java is using UTF-8 and Postgres is using Win1251,
> > >  the same character can be represented by different numbers.  You
> > > usually see this with special or non-english characters.  Your web
> > > app stores a string in the database, then you look at it with a
> > > database with a browsing tool and some characters are different or
> > > get returned as ???.
> > >
> > > This can play hell with MD5 calculations.
> > >
> > > > And, as far as confusing postgres users with tomcat users,
> > > > is there a problem with using the same user for both?  I kind of 
thought
> > > > that was the point.  When I create a user, they can use the same
> username
> > > > and password to access tomcat web apps that they use to connect to 
the
> > > > database.
> > >
> > > That only works if you wait to define connections inside your web
> > > app.  This severely limits the effectiveness of connection pools.
> > >
> > > That chews up huge amounts of resources in a web app used by lots of
> > > users because building and tearing down connections uses a lot of
> > > cycles and memory.
> > >
> > > Even if you pool in your web app each user will have their own pool
> > > and at least one real connection will have to be opened for each user.
> > >
> > > You can get around this on some databases if they let you set the
> > > role or the user on an open connection.  That is very non-standard
> > > and could cause problems if you switch databases.
> > >
> > > All users of a web app usually share the same database
> > > username/password in a connection pooled environment where you are
> > > using a dataSource.  It gets locked in at the time the dataSource is
> > > set up.  So all users of the web app have the same read, update,
> > > select privleges.  If you want to restrict that on a per user basis
> > > you have to enforce that in your web app, usually using Tomcat Roles.
> > >
> > > A Tomcat Role differs from a database Role, so you have to be
> > > careful there. You may or may not have access to the databases user
> > > Role table depending on the database.  The problem is that if your
> > > dataSource belongs to user "tomcat" and user "Joe" logs into the web
> > > app the database may not let tomcat look at Joe's database Roles for
> > > security reasons.
> > >
> > > >
> > > > Thanks for the pointers on security.  Both Tomcat and Postgres are on
> the
> > > > same server.  I'm also planning on using HTTPS, but apache will 
handle
> > > that
> > > > part.  I think it will work something like this:
> > > >
> > > > 1. user types username and password (clear-text) into form
> > > > 2. web browser encrypts everything and sends it to web server (https)
> > > > 3. apache decrypts everything and passes it onto tomcat
> > > > 4. tomcat makes a MD5 form of the given password
> > > > 5. tomcat compares this with the MD5 password taken from the database
> > > >
> > > > Does that sound right?
> > >
> > > Yes, with the caveats above.  Good Luck!
> > >
> > > Rick
> > >
> > > >
> > > > --
> > > > Robert Abernethy IV
> > > > Dynamic Edge, Inc.
> > > > 734.975.0460
> > > >
> > > > > Yeah, looks like you almost have it.  The MD5'd password should be

in
> > > > > pg_shadow in the userCredCol, passwd in this case.
> > > > >
> > > > > Be advised that you should either use only HTTPS for this, or run
> > > > > Tomcat on the same server as Postgres, or run them both on a secure
> > > > > net behind a firewall on separate machines to prevent your Postgres
> > > > > database from being compromised.
> > > > >
> > > > > MD5 really only prevents snoops on your server from being able to
> easily
> > > > > read the passwords in pg_shadow.
> > > > >
> > > > > Rick
> > > > >
> > > > > ----- Original Message -----
> > > > >
> > > > > > * Rob Abernethy IV <abernethy@dynedge.com> [0154 21:54]:
> > > > > > > OK. I was able to get clear-text passwords to work, but
I still
> > > can't
> > > > > get
> > > > > > > encrypted passwords to work.  Using MD5 encryption, Tomcat
is 
able
> > > to
> > > > > > > successfully open a connection to the database using the

JDBCRealm
> > > set
> > > > > up in
> > > > > > > the server.xml, but it is unable to authenticate users
for the
> admin
> > > > web
> > > > > app.
> > > > > > >  I am using the same username and password (username 
= "tomcat",
> > > > > password =
> > > > > > > "tomcat") for both the JDBCRealm and the admin web app.
> > > > > > >
> > > > > > > JDBCRealm:
> > > > > > > <Realm  className="org.apache.catalina.realm.JDBCRealm"

debug="99"
> > > > > > >        driverName="org.postgresql.Driver"
> > > > > > >     
connectionURL="jdbc:postgresql://bilbo.dynedge.com/template1"
> > > > > > >    connectionName="abernethy" connectionPassword="gceIlu4DaR"
> > > > > > >         userTable="pg_shadow" userNameCol="usename"
> > > > userCredCol="passwd"
> > > > > > >     userRoleTable="pg_groupview" roleNameCol="groname"
> > > > > > >            digest="MD5" />
> > > > > > > pg_shadow:
> > > > > > > usename  | passwd
> > > > > > > -------------------------
> > > > > > > tomcat   | md5efcc1c51a80be13b59cdb96d758a0184
> > > > > >
> > > > > > You are confusing postgres usernames/passwords with the ones
you
> want
> > > in
> > > > > the tables.
> > > > > > Tomcat connects to the database as user connectionName , password
> > > > > connectionPassword
> > > > > >
> > > > > > and looks up http authentication users and passwords in userTable
> and
> > > > > userRoleTable.
> > > > > >
> > > > > > It looks from your post like you have that backwards (pg_shadow
> holds
> > > > > postgres users, not users
> > > > > > for your apps).
> > > > > >
> > > > > > > postgresql log (for admin web app authentication):
> > > > > > > Jan  7 16:43:34 bilbo postgres[4329]: [9] LOG:  query:
SELECT
> passwd
> > > > > FROM
> > > > > > > pg_shadow WHERE usename = 'tomcat'
> > > > > > > Jan  7 16:43:34 bilbo postgres[4329]: [10] LOG:  duration:
> 0.001636
> > > sec
> > > > > > >
> > > > > > > catalina_log.2003-01-07.txt:
> > > > > > > 2003-01-07 16:43:34 JDBCRealm[Standalone]: Username tomcat
NOT
> > > > > successfully
> > > > > > > authenticated
 > > > > > >
> > > > > > --
> > > > > > Rasputin :: Jack of All Trades - Master of Nuns
> > > > >
> > >
> > > --
> > > To unsubscribe, e-mail:   <mailto:tomcat-user-
> unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail: <mailto:tomcat-user-
> help@jakarta.apache.org>
> >
> > --
> > To unsubscribe, e-mail:   <mailto:tomcat-user-
> unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:tomcat-user-
> help@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:   <mailto:tomcat-user-
unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-user-
help@jakarta.apache.org>
------- End of Forwarded Message -------



--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message