tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Abernethy IV" <aberne...@dynedge.com>
Subject Re: JDBCRealm
Date Fri, 10 Jan 2003 08:26:21 GMT
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>


Mime
View raw message