The scenario that is described here is a perfectly valid use of session. We can never know that user terminated the browser, so the only thing we can do is to look for old sessions and purge old one after some lengthy inactivity. There is already a session timeout mechanism in place. Reusing own cookie in different browser is definitely not a security issue.
"This should reduce the chance of someone capturing the cookie value on the network and using it" is not right... Once you get access to someone's cookies it is pretty much game over.
We have a session timeout code and we are setting proper security flags on our cookie - that is far far more important!
Email change with password? This doesn't make it more secure. Sending confirmation to previous and already verified email is the best way to confirm it is you. However, I do realise that email is not a required field in Mahara. Also, how would this password confirmation work with SSO?
Got an email about this issue.
The scenario that is described here is a perfectly valid use of session. We can never know that user terminated the browser, so the only thing we can do is to look for old sessions and purge old one after some lengthy inactivity. There is already a session timeout mechanism in place. Reusing own cookie in different browser is definitely not a security issue.
"This should reduce the chance of someone capturing the cookie value on the network and using it" is not right... Once you get access to someone's cookies it is pretty much game over.
We have a session timeout code and we are setting proper security flags on our cookie - that is far far more important!
Email change with password? This doesn't make it more secure. Sending confirmation to previous and already verified email is the best way to confirm it is you. However, I do realise that email is not a required field in Mahara. Also, how would this password confirmation work with SSO?
Re: the user agent, I am not sure if that is a good idea either. According https:/ /www.owasp. org/index. php/Session_ Management_ Cheat_Sheet# Binding_ the_Session_ ID_to_Other_ User_Properties it is a good thing to capture, but does nothing against skilled hackers. If we need to add a user agent, it can be added to $_SESSION itself, no need to modify database structure.
Optional IP locking might be a good thing to add. It is rarely used this days, but can be useful when necessary.