1552: Need option to expire cookies
- WontFix
- Review Board
| nah****@gmai***** (Google Code) (Is this you? Claim this profile.) | |
| March 27, 2010 |
What version are you running? Review Board 1.5b1 Please provide any additional information below. The review board cookie expires 1 year after login. This is unsafe when using public computers or sharing an account. There is should at least be an option in the admin panel to set them to expired at then end of the session, i.e. force the user to login at each new session. Optionally, the admin could select a different the duration (a week, a month, forever, ...). Another feature would be to allow the user to chose a shorter duration at login time
Will have to investigate this. Might be able to do it for 1.5, but it's likely it'll slip to 1.6 given the current work load.
-
+ Confirmed -
- Type-Defect - Priority-Medium + Type-Enhancement + Priority-Low + Component-Accounts + Milestone-Release1.5
I don't actually think this is worth doing. The way most modern webapps tend to work is that they have a long-lasting cookie, and users who are on public computers or sharing an account can log out (the link is prominent in the upper right). If you really want this you can make a change in your local source but I don't want to clutter our UI up with random options like this.
-
- Confirmed + WontFix
You can't rely on people to remember to logout, if they even want to bother. Asking them to do that is not an option. A source review website is not just your regular blog or your classmate website. There can be quite a bit of trade secrets or other IPs in a diff. So unless you want to cater only to open-source projects, you should really consider this as a security leak more than just an enhancement. As for the UI clutter, call me dubious when there is a setting for "code profiling". But if you really believe the UI is an issue, then you ought to have a configuration file for those extra features.
I would hope that Review Board instances with company secrets are not on the public Internet being accessed in libraries and other public computers. That said, you can actually do what you want today. Edit your site's conf/settings_local.py file and add: SESSION_EXPIRE_AT_BROWSER_CLOSE = True
More than libraries or other public computer, I was thinking of stolen laptops or PDAs. But even then, there are secrets and secrets. Some, like military or state secrets that may need draconian protection. But some are just to keep ahead of the competition and authentication with SSL is good enough. I didn't know about settings_local. I'll have a look. Thanks for the tip. But I may want to look at some extra precautions. Given the way Trowbrds dismissed this bug indicates that security is not taken really seriously and makes me worry about other security holes.
I certainly didn't mean to give you the impression that I don't care about security. I do, it's just that when it comes to security, cookie expiration doesn't make a difference one way or the other. For stolen endpoints, you still would have the problem of browser history and cache. The only way to prevent data from being stored on-disk here is to run a browser in incognito/private mode, in which case the cookie isn't a problem anyway. The real way to protect your secrets on these devices is to have the device locked in some way (authentication turned on, perhaps encrypted filesystems, etc). If a secret is important enough that you're willing to inconvenience your users over it (login every time, or encrypted laptop filesystems+login, etc), it's really worth putting your reviewboard server behind a VPN.
VPN doesn't solve the problem of caching. If the cookie is expired, unless you put information in the URL itself, browser history will not divulge much either. As for the cache, a browser can be configured to not save encrypted pages. And otherwise, it will only give read access to "recent" reviews, not write access to any and all reviews. Expiring cookies may not be the panacea in security but it's still better than non expiring ones. Anyway, I'll look at settings_local. Thanks.
We don't take security lightly, but you must understand that every corporate scenario we've seen so far has a Review Board server behind a corporate firewall/VPN, and so we optimize for that. I have a strong feeling that if we added a checkbox for this setting, it would not be used by more than one or two installs. Those installs are already in trouble, because, while security is important, we can't guarantee that Review Board, Django, Djblets, Pygments, Python, paramiko, mod_python, Subversion, Git, Apache, and every other thing in our stack is secure and free of bugs that would allow a user to take control over a system. If your setup is such that a stolen laptop or PDA can be used to access your Review Board server, then that's a security problem with your overall install, not the software. Just as you would hopefully not make your entire repository accessible to the outside world without a VPN, you shouldn't make your Review Board server accessible. And if you are accessing even your internal server with a portable computer/device, then it's your responsibility to secure it and make sure that, if it's stolen, they can't get access to anything. Many companies have a policy for using encrypted filesystems for this very reason. Sorry if it seems like security isn't a priority to us. It is. This is not a solution for it though, at least not one that will do anything other than give the illusion of solving the problem.