On Tue, Jun 21, 2011 at 4:02 AM, André Brunnsberg < andre.brunnsb...@planmill.com> wrote:
> But if the user has the session then he or she can change the user > credentials Actually it depends on how application that implement password change. Usually for changing the password you need to enter the current password also. > (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. > If we start speculating we can reach any scenario.. You are telling me IF the system has a user registration use case and IF the hacker HAPPENS to get an admin session, he can add a new user. That the hacker can do if the user go for a walk and forget to look the screen too. > Remember how easy it is to hijack cookie files under normal HTTP with the > Firesheep extension for Firefox. > I am not trying to prevent session hijacking. That's not a requirement for this system. The requirement is to secure the user password. I believe this is a meaningful requirement. > 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 > > -- Rafael Liu +55 61 9608-7722 http://rafaelliu.net
