tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arnold Shore" <ash...@dgs.dgsys.com>
Subject RE: Implementing JDBC realm with encryption
Date Thu, 03 Jan 2002 13:36:25 GMT
I'm doing just that in a non TC shop.  Here's how:

1.  At the server, generate the random string, retain that (in any
convenient manner) as associated with the SessionID - or IP, and also send
it to the browser in the login page as a hidden variable.
2.  At the browser, concatenate the entered password with the random, hash
that, and send the userid and the hash to the server.
3.  At the  server, and using the userid as the lookup, pull the password,
concatenate that with the (retained) random, hash that string, and match the
hash to the value from the browser.

Pretty straight-forward, IMO

Arnold Shore
Annapolis, MD USA

-----Original Message-----
From: Roland [mailto:roland@netquant.com.br]
Sent: Thursday, January 03, 2002 8:07 AM
To: Tomcat Developers List
Subject: Re: Implementing JDBC realm with encryption



> > Hello,
> > I want to implement my own JDBC realm with browser side-password
> > encryption. The idea is to hash the password together with the sessionId
> > and a random variable using SHA-1 on the browser side with Javascript.
The
> > hash is then send to the server. This prevents hackers from retrieving
the
> > password in plain text from the internet. Has anything like this been
> > implemented already? How do I start to implement it myself?
> >
>
>I think you might be confusing some concepts -- a Realm doesn't talk
>directly to a browser.  Let's divide up the transaction like this:
>
>
>   Browser   ---username/password--> Container ---username/password-->
Realm
>
>
>Now, are you concerned about encrypting the Brower-->Container or the
>Container-->Realm path?  The two are completely independent of each other:

I'm concerned about encrypting the Browser-->Container path. The problem
with my particular approach is, that I will send a Sha-1 hash from the
browser to the container. The container will have no means to retrieve the
original password from the hash. The means, that the Realm will only
receive a hash of the password(and the sessionId). So the realm has to know
this and act accordingly. In this case that means that the realm would have
to retrieve the password from the JDBC database(assuming a JDBC realm here)
hash it with the actual sessionId from the requesting user and compare the
received hash with the produced hash to see if they match. So the realm has
to be changed accordingly knowing that it won't receive a plain text
password.

>* For Browser->Container, the best thing to do is use
>   DIGEST (if your browser supports it) or CLIENT-CERT
>   authentication.  In those cases, the password that
>   goes across the wire is already encrypted for you.

Thats fine, but AFAIK those two methods suppose some underlying technologie
like SSL. But what if SSL is not available? My idea is to provide an
ecryption that is independent of any underlying technologie. The generation
of the hash on the browser would just be a little javascript(already
implemented). The only thing to change would be on the Container/Realm side
to be able to process the generated SHA-1 hash correctly.

>* For Container-->Realm, the existing Realm implementations
>   have the ability to store the password in an encrypted
>   form (rather than clear-text).  See the server configuration
>   documentation about realms - in particular the "digest"
>   attribute.

I knew that, but my point is really to encrypt the password at the browser,
so that it doesn't get sent over the internet in plain text format.

Roland


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


Mime
View raw message