On Jun 16, 11:08 pm, Anthony <abasta...@gmail.com> wrote: > On Thursday, June 16, 2011 6:02:00 PM UTC-4, blackthorne wrote: > > > Anthony: I don't really understand how would that solve the problem. > > The problem has to do with transmission of the session cookie in a non > > secure channel. Regenerate it won't solve the problem. > > It will solve the problem of transitioning from an insecure/pre-login > session to a secure/post-login session, which is a separate issue. > I see you assume that the pre-login established session is the same after login. I consider them as 2 different sessions, so yes regenerate=True as you say is what I assume that should be the default behavior when creating an authenticated session. At least, your proposal should be available if we want to be able to warrant authenticity.
> > We need to > > enforce not to allow the transmission of authenticated sessions threw > > non secure channels. I think this should be the default behavior. > > I'm not sure the framework should absolutely require SSL in order for the > auth system to work at all. Using any sort of method, providing authentication is more than just saying who you are which is technically the only thing you are doing when transmitting a session cookie in a non secure channel. it's about proving that you are who do you say. While sending a username, password to a website the user is trusting in the best practices on handling those credentials safely. Those expectations should be met by making the possible to prevent, at least, the publicly known "cheap" attacks. So, I'm not against the possibility of allowing non secure channels, just defending this behavior as the one I consider that should be default. > > Anthony
