You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Roland <ro...@netquant.com.br> on 2002/01/03 14:06:47 UTC
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Why do I receive CVS-commit stuff?
Posted by Bojan Smojver <bo...@binarix.com>.
Quoting Roland <ro...@netquant.com.br>:
> Hello, I'm subscribed to the tomcat-dev mailing list but keep receiving
>
> cvs-commit emails. Why is that? Here are some of the headers of the
> emails
> I receive:
>
> From: remm@apache.org
> To: jakarta-tomcat-4.0-cvs@apache.org
> Subject: cvs commit:
> jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session
> StandardManager.java
>
> Can someone turn this off please?
I think you're misunderstanding the purpose of the -dev list. Developers need to
know who commits what to the CVS. Therefore the messages. At a number of
occasions bugs in commits have been spotted that way.
Bojan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Why do I receive CVS-commit stuff?
Posted by Martin van den Bemt <mv...@mvdb.com>.
That is just the reason why you receive them. Since it is a "we are the
people who develop tomcat" mailinglist and therefor the commit messages are
very usefull (keeping track of changes..).
If you develop applications (webapps) that run under tomcat, the tomcat-user
mailinglist is a more appropiate place.
So we like to keep the commit mails (at least I do..)
Mvgr,
Martin
-----Original Message-----
From: Roland [mailto:roland@netquant.com.br]
Sent: Thursday, January 03, 2002 14:55
To: Tomcat Developers List
Subject: Why do I receive CVS-commit stuff?
Hello, I'm subscribed to the tomcat-dev mailing list but keep receiving
cvs-commit emails. Why is that? Here are some of the headers of the emails
I receive:
From: remm@apache.org
To: jakarta-tomcat-4.0-cvs@apache.org
Subject: cvs commit:
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session
StandardManager.java
Can someone turn this off please?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Why do I receive CVS-commit stuff?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 3 Jan 2002, Roland wrote:
> Date: Thu, 03 Jan 2002 11:55:20 -0200
> From: Roland <ro...@netquant.com.br>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: Why do I receive CVS-commit stuff?
>
> Hello, I'm subscribed to the tomcat-dev mailing list but keep receiving
> cvs-commit emails. Why is that? Here are some of the headers of the emails
> I receive:
>
> From: remm@apache.org
> To: jakarta-tomcat-4.0-cvs@apache.org
> Subject: cvs commit:
> jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session
> StandardManager.java
>
> Can someone turn this off please?
>
I'm afraid not.
The presumption here, as well as most other Jakarta projects, is that
anyone subscribed to a DEVELOPER mailing list is interested in seeing what
is actually happening to the code, as well as the discussions among the
developers. Therefore, the CVS commits (as well as changes to the
Bugzilla bug reports) are automatically reflected to TOMCAT-DEV.
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Why do I receive CVS-commit stuff?
Posted by Roland <ro...@netquant.com.br>.
Hello, I'm subscribed to the tomcat-dev mailing list but keep receiving
cvs-commit emails. Why is that? Here are some of the headers of the emails
I receive:
From: remm@apache.org
To: jakarta-tomcat-4.0-cvs@apache.org
Subject: cvs commit:
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session
StandardManager.java
Can someone turn this off please?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Implementing JDBC realm with encryption
Posted by Kief Morris <ki...@bitbull.com>.
Roland typed the following on 11:06 AM 1/3/2002 -0200
>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 means, that the Realm will only
>receive a hash of the password(and the sessionId).
...
>But what if SSL is not available? My idea is to provide an
>ecryption that is independent of any underlying technologie.
...
>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.
This seems pointless to me. If the server will authenticate based on receiving
the hashed password+sessionId, then the black hats don't need the password,
just the hash. If you're sending the hash in the clear, they can steal it and
hijack the session. There's little gain over sending a plaintext password,
other than limiting the window for exploitation by expiring the validity of the
hash.
Kief
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Implementing JDBC realm with encryption
Posted by Arnold Shore <as...@dgs.dgsys.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>