tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McBride <>
Subject Re: interaction between .forward() and <security-constraint>
Date Mon, 13 Sep 2010 21:33:43 GMT
  Hi Christopher,

On 13/09/2010 19:58, Christopher Schultz wrote:
>> That's a bit of a worry.   Can you say any more about the edge cases I
>> should be concerned about.
> Well, if Tomcat intercepts a request in order to perform authentication,
> then the filter will not be called during that request/response
> transaction. That's probably - specifically - not a problem because the
> whole point of the transaction is authentication... presumably you're
> not delivering protected resources /during/ authentication.
Your are right.  The filter may kick in during a 'normal' transaction to 
require authentication before it can proceed, but no restricted 
resources are delivered during authentication.
> I hadn't really thought about what those edge cases were... I just
> wanted to point out that, when considering authentication and
> authorization code, you really need to think /hard/ about every
> possibility, because failure to do so may leave you open to exploitation.
I'm fumbling about seeking the hardness knob that controls my thinking 
... I know its there somewhere ... :)

>> I don't want to store users passwords, I want to store some digest of
>> them.   To protect against dictionary attacks on the password database I
>> want to store salted passwords - i.e. add a larg'ish random number to
>> each users password before taking the digest.  I couldn't see how to use
>> salted password storage along with HTTP DIGEST authentication.
> Neither FORM nor BASIC/DIGEST authentication in Tomcat support salted
> passwords without you writing some of your own code.
It's good to have that confirmed.
>> So I've written my own based on HTTP DIGEST but where the challenge
>> includes the salt so the client can compute the users effective password.
> Do you intend for regular web browsers to be able to support this? I
> don't think this is possible in the real world unless you control 100%
> of the clients.
I have two sorts of clients - applications where I can specify what's 
required, and browsers where I can assume the use javascript.  I have 
some javascript that will compute the response to a challenge and send 
it off to the server.
> HTTP DIGEST authentication is, unfortunately, likely to just die and go
> away.
I'm learning from the discussion on this list that DIGEST is not very 
popular.  However, it is a published algorithm and therefore has a bit 
more credibility than one I cooked up.

> It's been designed around the MD5 digest algorithm which is, these
> days, considered relatively unsafe.
The basic changes I have made are to switch from MD5 to SHA-256 and add 
a 64 bit salt to the users password.
>   There is no protocol through which
> the client and server can negotiate a digest algorithm, so MD5 is always
> assumed. Hopefully, DIGEST will be replaced by something like DIGEST2
> with a better negotiation protocol so that it can be extended into the
> future as new crypto primitives become available and old ones are retired.
That would be great.
>> Another variation I am trying is to associate a user not with a session
>> but with an SSL session.  Each SSL session must be authenticated.  This
>> prevents someone snooping/guessing the JSESSIONID ( some of my traffic
>> is in clear and the JSESSIONID is therefor not secure)  and using a
>> different SSL connection and faking the JSESSIONID to get access.
> That might work, but SSL sessions and user sessions aren't always 1:1.
> For instance, the SSL session might expire and be renegotiated while the
> "user session" should remain the same.
Hmmm, yes, that could be bad.  Well at least that way round its secure - 
it just means the client may have to authenticate again.  I don't know 
what control I can have over SSL sessions expiring.  The other issue is 
multiple SSL sessions in the same user session.  A programmatic client 
can take care of that - the browser access should not need multiple 
sessions  - but I'll only know if this is a problem when I've built 
enough of it to tell.

One thing I'm slightly nervous of is reuse of the SSL session id.  The 
SSL spec says the server gets to choose the ID for an SSL session so I 
need to know that the server doesn't reuse them in a way that might 
compromise this approach.  OpenSSH states that it uses a random number 
as wide as the protocol allows.  Haven't found a statement about what 
JSSE does and haven't had an answer yet to my question to the forum.  I 
expect its fine - it would just be nice to have it in writing.

I appreciate the input and comments.


> - -chris
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla -
> BHcAn2e1u/ggle9cjWmNebKLXAXHuSah
> =co+W
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message