Hey Chris, as you said, each problem compromise different kinds of things: account vs credentials. And I think they have different kind of consequences and can be, each one , dangerous its own way. I brought the discussion into the list because I thought it was relevant.
Looking at the code, a fix would be quite simple: replacing the forward() by a send(). To have the same behaviour as today to the end user, a few more things should be done, because we would be changing from a POST to a GET, but AFAIK it's a matter of saving the target URL as a request parameter. Back button, bookmark and normal login should work. I agree it's kind of a philosophical question but I see some real implications. Anyway, for the record, as a quick and dirty fix I set the full URL with https schema in /form@action. But the hosting page isn't HTTPS and the user may feel unsecure.. On Tue, Jun 21, 2011 at 11:46 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rafael, > > On 6/20/2011 8:12 PM, Rafael Liu wrote: > > Good point Chuck. I agree with you, the webapp wouldn't be all secured. > But > > there are 2 different things here: > > > > * the issue with the plain password > > * the issue with session hijacking > > This does become somewhat of a philosophical question. I agree that > credentials should always be secured. If the service itself is not > particularly sensitive, I think it's acceptable to use SSL only during > authentication. > > Be aware that some authentication schemes (i.e. HTTP Auth) send > credentials on every request, not just the first time they are challenged. > > > The first one first gives the hacker a private information about the user > > (which can even the used by the user somewhere else). The hacker will > have > > the actual user's credentials, and will be able to login at will. > > > > The second one doesn't necessarily exposes user's informations. The > hacker > > can pretend to be the user, but only for the time of the session. Even > tho > > there are tricks to keep the session alive [almos] forever, this is > > essentially different from having the user's credential. > > If the system doesn't require the existing password to be supplied > (again, in SSL!) in order to do things like change the password, then an > attacker can hijack the session and then hijack the account. The > credentials are still safe, but the account is not. > > > I see them at different levels of security. Using the same logic, one can > > say that there's no point in using DIGEST authentication if there's still > > room for session hijacking. Much like BASIC / DIGEST or CONFIDENTIAL / > > INTEGRAL provides different levels of security, I think the two cases > > mentioned also do. Giving these kind of options to the webapp can make > NFR > > (like performance) easier to meet and infrastructure easier to configure > > (like rewriting on Apache). > > +1 > > The right answer is: always think about what you are doing. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk4Arq8ACgkQ9CaO5/Lv0PB4VwCgvU23AGCJ/8ChMOJ/RsWuM3zG > hxQAoKykpgMpWlPX3wL52zi+N0gQep9c > =xeZL > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Rafael Liu +55 61 9608-7722 http://rafaelliu.net
