"IP address has changed. Please log in again"
Hello koha-devel, Some of our customers are reporting that they sometimes need to login after getting this message on the staff interface. - one of them is running Plack (in production), he faces this problem many times an hour, on every workstation (we've commented the lines in C4/Auth.pm to avoid this problem, because it was really a nightmare) - some of them are in CGI mode, behind a proxy, and the problem occurs a few times a day, or even less. Has anyone faced this problem ? how did you solve it ? -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper
Hi, On Wed, May 29, 2013 at 8:30 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
- some of them are in CGI mode, behind a proxy, and the problem occurs a few times a day, or even less.
We've occasionally run into problems with proxies changing the IP address. If your customer has control of the proxy, they should configure it to allow direct access to the Koha database, or at least route traffic through only one of the proxy servers. There is additional discussion of this in bug 5511 [1]. The bug includes a patch to add a system preference to disable the IP address check, but of course doing that would make it easier to hijack the session. I'll ask the same question here that I asked in the bug: Given the continued existence of things like web proxy farms that can result in REMOTE_ADDR changing from request to request, are there any improvements in the state of the art for anti-session-hijacking measures that would reasonably allow us to remove the IP address check (or implement a syspref like Amit's patch tried)? [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5511 Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Galen Charlton schreef op wo 29-05-2013 om 09:07 [-0700]:
I'll ask the same question here that I asked in the bug: Given the continued existence of things like web proxy farms that can result in REMOTE_ADDR changing from request to request, are there any improvements in the state of the art for anti-session-hijacking measures that would reasonably allow us to remove the IP address check (or implement a syspref like Amit's patch tried)?
Standard session cookies combined with running over HTTPS is really the only way. It comes down to threat modelling really: is session hijacking something that you feel you care about? (It's perfectly reasonable to say either yes, no, or only on the staff client, depending on your circumstances.) To make it a bit more secure we could use a different session for the staff client vs. the OPAC. At the moment we use the same for both, so someone capturing a session cookie from a staff member logged into the OPAC can use that to access the staff client. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
Hi, On Wed, May 29, 2013 at 3:58 PM, Robin Sheat <robin@catalyst.net.nz> wrote:
Standard session cookies combined with running over HTTPS is really the only way. It comes down to threat modelling really: is session hijacking something that you feel you care about? (It's perfectly reasonable to say either yes, no, or only on the staff client, depending on your circumstances.)
I'd personally be happy with requiring SSL for the staff interface and the OPAC throughout on the basis that patron information is sensitive enough to demand that level of care. However, because of the general support issues that would arise around SSL certs, I suspect that Koha jumping on the HTTPS Everywhere bandwagon will likely have to remain a recommended practice rather than a requirement or installation default.
To make it a bit more secure we could use a different session for the staff client vs. the OPAC. At the moment we use the same for both, so someone capturing a session cookie from a staff member logged into the OPAC can use that to access the staff client.
I think this is a good idea. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Please don't force HTTPS in the software. I'll explain why I'm making that request here. First, it's easy to force HTTPS in the apache config for the vhosts, I've done this. It's a simple matter of a redirect on the port 80 vhost pointed at the https vhost. This is where certificates would likely be configured anyway, so I think this is a reasonable way to do it. I've been playing with setting up a web server farm, with a fail-over pair of reverse-proxy servers as the front. As a performance measure communication between the proxies and the worker nodes is done over plain http (because I trust my LAN enough for that). I ran into a problem with my tests though where a web app forced https in the software, it produced a redirect loop, because the worker would respond with a http meta redirect to the https port but the web browser was already using that port. Luckly I would turn off that feature in the software. I understand that forcing https in the software is a good security measure. I'm just asking that it be controlled by a system preference, or be made an optional section in the apache config file in consideration of those who would like to avoid the overhead added by https. Thanks for your consideration. On Thu, May 30, 2013 at 12:18 PM, Galen Charlton <gmc@esilibrary.com> wrote:
Hi,
On Wed, May 29, 2013 at 3:58 PM, Robin Sheat <robin@catalyst.net.nz> wrote:
Standard session cookies combined with running over HTTPS is really the only way. It comes down to threat modelling really: is session hijacking something that you feel you care about? (It's perfectly reasonable to say either yes, no, or only on the staff client, depending on your circumstances.)
I'd personally be happy with requiring SSL for the staff interface and the OPAC throughout on the basis that patron information is sensitive enough to demand that level of care.
However, because of the general support issues that would arise around SSL certs, I suspect that Koha jumping on the HTTPS Everywhere bandwagon will likely have to remain a recommended practice rather than a requirement or installation default.
To make it a bit more secure we could use a different session for the staff client vs. the OPAC. At the moment we use the same for both, so someone capturing a session cookie from a staff member logged into the OPAC can use that to access the staff client.
I think this is a good idea.
Regards,
Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Hi, On Thu, May 30, 2013 at 3:07 PM, Michael Hafen <michael.hafen@washk12.org> wrote:
I understand that forcing https in the software is a good security measure. I'm just asking that it be controlled by a system preference, or be made an optional section in the apache config file in consideration of those who would like to avoid the overhead added by https.
I'm not sure I necessarily buy that the computational overhead for SSL is a major factor nowadays for anything but the most ancient of hardware. I grant that load balancers speaking to HTTPS backends can have configuration issues that are sometimes more easily addressed by letting the backends speak HTTP. Regardless, I do think that the Apache virtualhost configuration would be the right place to do an SSL-only configuration, either as a default or just a commented-out recommendation. Koha's CGI scripts don't need to enforce it. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Galen Charlton schreef op do 30-05-2013 om 11:18 [-0700]:
I'd personally be happy with requiring SSL for the staff interface and the OPAC throughout on the basis that patron information is sensitive enough to demand that level of care.
All our deployments now are using SSL, we strongly recommend it for exactly this reason. Also that if it's tied in to an LDAP infrastructure, passwords should never exist in plaintext (also people reuse passwords.)
However, because of the general support issues that would arise around SSL certs, I suspect that Koha jumping on the HTTPS Everywhere bandwagon will likely have to remain a recommended practice rather than a requirement or installation default.
Yeah, it requires a substantial amount of setup and knowledge. Also it interacts badly with cover images, which are fetched over HTTP, and so you get mixed content warnings. Where possible, they should use HTTPS if the system is, but it's not always possible. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
participants (4)
-
Galen Charlton -
Michael Hafen -
Paul Poulain -
Robin Sheat