-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian,
On 9/12/2010 4:18 PM, Brian McBride wrote: > On 09/09/2010 19:47, Christopher Schultz wrote: >> I'm sure there are some edge cases where an authenticated user might end >> up looking like a "guest", but you cna probably solve those. > > 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. 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. >> If you >> always use HTTP Authentication (it wasn't clear what was really going >> on, with all that talk about DIGEST authentication), then you can always >> get the username from the request headers. In that case, your filter can >> use that as a source of authentication data, too. > > I was hoping to use http authentication so I could use well debugged > code rather than write my own. But I've currently given up on that. I meant using HTTP BASIC vs FORM authentication -- both are well-tested. > I wasn't happy with BASIC authentication on the grounds the password > leaves the user's machine. Even if its safe on the wire because of SSL, > there is always the chance it will leak from the server end somehow. I > want to be sure I never know the user's actual password. Sounds like a good idea. > 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. > 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. HTTP DIGEST authentication is, unfortunately, likely to just die and go away. It's been designed around the MD5 digest algorithm which is, these days, considered relatively unsafe. 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. > 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. - -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
