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.
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 logins 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.
Thanks and regards,
krishnan mani
Pune, India
Add more friends to your messenger and enjoy! Go to
http://messenger.yahoo.com/invite/_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha.org
http://lists.koha.org/mailman/listinfo/koha-devel
