On 21/06/2011 17:05, Rafael Liu wrote: > 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.
The spec requires that POST is used. > 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.. And rightly so. If the login page is not delivered over SSL that opens the way for various MITM middle attacks. > On Tue, Jun 21, 2011 at 11:46 AM, Christopher Schultz < > [email protected]> wrote: > > 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. That is very much the minority view. I find it very hard to imagine any scenario where a user needs to be authenticated (and hence the password needs to be protected) but it is OK for the session to be compromised without that being considered a security breach. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
