Improvements to security and data privacy RFC

Introduction

With growing Koha usage at large public libraries and exposure of the OPAC (and in several cases, the Intranet interfaces) to audiences over the (big, bad) public Internet, the Koha community needs to be increasingly sensitive to security and data privacy.

If not, it is possible that Koha systems may present easy targets to unscrupulous people looking for potentially sensitive patron information that may be compromised and abused.

In this regard, Koha is not current with many commonly-accepted mechanisms to improve overall security. Moreover, these mechanisms (IMHO) can be easily added to Koha without disproportionate effort. The most cost-effective way of improving security of any system is to build the security into it upfront.

The first version of this RFC was authored by krishnan mani, krishnanm75 [AT] yahoo [DOT] com

Suggested improvements

S1. E-mail confirmation workflow

Background

At account creation, Koha now has the option (using a template) in 'Notification' to send e-mail to an e-mail field on the patron records. The default template even includes the login name and password (in cleartext).

Issue

Any errors in specifying or recording e-mail address will send account creation (or other) e-mail to the wrong person. With the default template, such errors will directly allow another person to login to the member’s account.

Improvements

1. To introduce an e-mail workflow requiring patrons to confirm membership. Koha can send account details after confirmation of membership. (An example is the workflow for users signing up to Koha mailing lists)
2. To change the default template to include only a one-time password (or one-time login facility) (to be described below)

S2. About passwords

Background

Login passwords are not temporary and there is no mechanism to force users to change passwords. While Koha suggests a password to be set at the time of account creation, this means that at least one staff member knows passwords or may set them to something that is trivially weak.

Currently, a system preference allows administrators to specify (only) a minimum character length for passwords.

Issue

More than one person is involved and has knowledge about passwords being set/reset. This introduces potential human error in communicating passwords during account creation or password reset

Suggested improvements

1. Introduce one-time passwords (or one-time login links) automatically generated and e-mailed by Koha
2. Change the default account creation template shipped with Koha to include a one-time password/link allowing time-bound one-time login
3. Force users to change first-time passwords immediately on login
4. Staff to only request Koha to reset the passwords on accounts rather than set actual passwords.
5. Provide a self-service facility to users to request new passwords (or to reset passwords via a one-time login). Users are authenticated using a configurable piece of information from patron records that is used to construct ‘challenge’ questions.
6. Disallow display of passwords in cleartext anywhere in Koha or in e-mail notification
7. Enhance checks for password strength by checking for, some combination of uppercase and lowercase characters, numerals, and special characters. Add system preferences for administrators to specify the particular mix.
8. Allow administrators to specify a lifetime for passwords (say, 90 days), and have Koha force users to change passwords older than the same.

S3. Database access and ‘super-librarian’ login

Background

Koha stores the database user and password to (/etc/koha/)koha-conf.xml with the password in cleartext. This file is world-readable, and my own attempt to restrict access to this file breaks Koha. The same login and password is used to login to the Intranet post-installation, with ‘super-librarian’ privileges

Suggested improvements

1. Protect configuration files containing sensitive information and change Koha code to be able to read the same (This author is unaware of a suitable mechanism in Perl but recalls using the ‘requires’ facility in .php on products like Joomla)
2. Disallow logging into Koha using the database user and password
3. Create a one-time administrator login during installation to be used post-installation to create regular staff users.

S4. Print "last login" information upon logging in

This alerts users to any logins they may not recall and help detect any compromise attempts.

S5. Securing KOHA pages over SSL

Background

The OPAC login facility is available on most pages inline with other page content

Issue

If a site wants to secure, say, just logins, by serving those pages over SSL, it is currently not possible to do so without serving all of the site over SSL. This may not be acceptable considering potentially higher load and response times to serve content over SSL.

Suggested improvements

1. Separate the login page (as in the Intranet), so as to secure the same over SSL, and once the user is authenticated, the user can be redirected to regular content served over HTTP.
2. Allow configuring at installation time the use of SSL for some set of pages, including, for example, login, change password, patron profile pages, etc.
3. Simple instructions for admins to generate and use self-signed certificates for SSL may be included with the documentation.

S6. Improvements to disabling/enabling OPAC and Intranet access

At the moment, it is unclear whether clearing out the login and password field on a member record disables their login, and whether non-staff patrons have access to both OPAC and Intranet or just the OPAC. (the author is researching these) This can be remedied by simply providing an additional toggle to enable/disable login for a patron. This may also be useful in the event that a stray patron posts abusive content in tags or book reviews.

COMMENTS

I do not think S5.1 is desirable or technically possible without an additional mechanism. OPAC login utilizes cookies and browsers do not allow cross-site access to cookies between https: and http: domains, for obvious reasons. So you still have a problem getting the login "back" to the un-SSL OPAC pages, and you can't just pass parameters equivalent to the login because then you're no more secure than before. --atz