But if the user has the session then he or she can change the user credentials (of course only for this site unless the password is shown in the system, which would be really bad) or if the user has enough rights add a new user which can be used by the hacker. Remember how easy it is to hijack cookie files under normal HTTP with the Firesheep extension for Firefox. Cheers, André
-----Original Message----- From: Rafael Liu [mailto:rafael...@gmail.com] Sent: den 21 juni 2011 03:12 To: Tomcat Users List Subject: RE: Setting SSL for login pages 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 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. 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). What do you think? On Jun 20, 2011 6:50 PM, "Caldarale, Charles R" <chuck.caldar...@unisys.com> wrote: >> From: Rafael Liu [mailto:rafael...@gmail.com] >> Subject: Setting SSL for login pages > >> I think it would be natural something like this: > >> <security-constraint> >> <web-resource-collection> >> <web-resource-name>SSL login</web-resource-name> >> <url-pattern>/login/*</url-pattern> >> </web-resource-collection> >> <user-data-constraint> >> <transport-guarantee>CONFIDENTIAL</transport-guarantee> >> </user-data-constraint> >> </security-constraint> > > The login pages are usually not specified in the <url-pattern>; only > the pages to be protected. Login pages are not normally directly accessed by a user, but are only presented when the user attempts to access a protected page. > >> As I see, the way it is, all authenticated pages must be set to >> CONFIDENTIAL also > > Not also, instead. > >> But if the user IS authenticated he is forced to use HTTPS too, and >> that I was trying to avoid. > > Think about it: if the secure traffic is only for the login page, > anyone could access the not-really-protected pages by sniffing the sessionid used on the unsecure connection - you would have no security. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE > PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. > > > --------------------------------------------------------------------- > 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
