tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Liu <rafael...@gmail.com>
Subject Re: Setting SSL for login pages
Date Tue, 21 Jun 2011 12:04:34 GMT
On Tue, Jun 21, 2011 at 4:02 AM, André Brunnsberg <
andre.brunnsberg@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:rafaelliu@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.Caldarale@unisys.com>
> wrote:
> >> From: Rafael Liu [mailto:rafaelliu@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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


-- 
Rafael Liu
+55 61 9608-7722
http://rafaelliu.net

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message