Hi Christopher,
On 13/09/2010 19:58, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
[...]
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.
Brian
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyOdFYACgkQ9CaO5/Lv0PCU/gCgq98nOlMMX/NnRYdQU0ikoEre
BHcAn2e1u/ggle9cjWmNebKLXAXHuSah
=co+W
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
