[Koha] Securing login pages

[Jason Stephenson]

Quoting "Joe Atzberger" <ohiocore at gmail.com>:

> Chris --
>
> I think Jason means just serve the whole site as HTTPS, which is what we do
> and it works fine.  No template modifications are required.  The Apache
> config looks like:

Actually, no, I don't, but for what I mean to work, you will need to  
serve the whole site as SSL.

What we do on our mail server is force everyone using the Horde email  
client to use a SSL session. One way to do it is to use a rewrite rule  
in your *:80 virtual host:

<VirtualHost *:80>
         ServerName host.domain.tld
         Options +Includes
         RewriteEngine On
         RewriteRule ^/?(horde|dspam)/?(.*)$ https://host.domain.tld/$1/$2
         DirectoryIndex index.html index.php
</VirtualHost>

The above could be modified to work with a single page as well.

RewriteRule ^/?(login.pl)$ https://host.domain.tld/$1

That assumes, of course, that your page is in the document root for your site.

The above essentially rewrites the URL to force SSL on. You can also  
set certain locations so that they Require SSL.

When I sent my short message before, I neglected to mention that it is  
easiest to set up with a RewriteRule.

Note that I have not tried any of this with Koha, yet, so I don't know  
exactly what magic sauce you'd need in httpd.conf to make the login  
pages force SSL connections, but the above is 1 way that it is  
generally done.

Settings can get more complicated, and more useful, as I mention below.

>
> <VirtualHost *:443>
>    ServerName whoever.kohalibrary.com
>    SSLEngine on
>    SSLCertificateFile /etc/apache2/ssl.crt/whoever.kohalibrary.com.crt
>    SSLCertificateKeyFile
> /etc/apache2/ssl.key/whoever.kohalibrary.com.plainkey
> ....
>
> SSL protects against the exposure of data in transit, like say, during
> update of a borrower's password on the staff interface.  Nothing special
> gets done to that data, so it is just POSTed like any other form.  But SSL
> keeps it from being readily sniffable.  It can also be used for more
> advanced forms of authentication like client side certs (but if you're not a
> government contractor, it's unlikely your library needs to be *that* locked
> down).


SSL does 3 things:

1. It encrypts data in transit to prevent eavesdropping.
2. It can verify that the site you are connecting to is the site that  
it claims to be, but only if you trust the certifying authority.
3. It can verify that the person visiting the site is the person that  
they claim to be, again, only if you trust the certifying authority.

I have a server set up where a private location on the main site  
requires that anyone connecting to it use SSL and that they present a  
certificate that has been signed by my personal certificate authority.  
If you don't have it, you don't get in. This not only stops  
eavesdropping and assures that the users are connecting to the proper  
site, it also guarantees that only "authorized" people are using the  
site. It is also a very simple thing to revoke someone's certificate  
to block future access if their certificate has been abused.

I have long thought that SSL has been way underutilized for  
authentication scenarios such as I describe above. Many sites still  
rely on passwords and account names. Properly configured, a web site  
can even determine a particular user from information in the  
certificate, thus eliminating the need for a username/password  
combination when a certificate is used for authentication.

Of course, the user can (and should) use a password when importing  
their certificate into their certificate store if they fear their  
computer being stolen or used by someone else.

Sorry for the digression, but SSL has been one of my pet issues lately.

Cheers,
Jason

>
> --Joe Atzberger,
> LibLime, Systems Administrator
>
> On Fri, Aug 22, 2008 at 9:42 AM, Chris Cormack  
> <chris at bigballofwax.co.nz>wrote:
>
>> Hi Jason
>>
>> Yep that would work fine, if the login pages were separate urls,
>> instead they can be the same url as a page you might not want to
>> server ssl. Eg opac-main.pl :)
>>
>> So you would have to rejig some timeplates too.
>>
>> Chris
>>
>> On Sat, Aug 23, 2008 at 1:01 AM, Jason Stephenson <jstephenson at mvlc.org>
>> wrote:
>> > If you are using Apache to serve your Koha pages, then you can
>> > configure individual pages to force SSL.
>> >
>> > Check the Apache documentation for Location and SSL.
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Koha mailing list
>> > Koha at lists.katipo.co.nz
>> > http://lists.katipo.co.nz/mailman/listinfo/koha
>> >
>> _______________________________________________
>> Koha mailing list
>> Koha at lists.katipo.co.nz
>> http://lists.katipo.co.nz/mailman/listinfo/koha
>>
>