[Koha-devel] RFC: Improvements to Koha security and privacy

Sun Oct 12 00:11:37 CEST 2008

On Wed, Oct 8, 2008 at 3:49 AM, Krishnan Mani <krishnanm75 at yahoo.com> wrote:

> 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
>
> ------------------------------
> Share files, take polls, and make new friends - all under one roof. Click
> here.<http://in.rd.yahoo.com/tagline_groups_8/*http://in.promos.yahoo.com/groups/>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha.org
> http://lists.koha.org/mailman/listinfo/koha-devel
>
>
These sound fairly reasonable. Could you put them on the wiki under
http://wiki.koha.org/doku.php?do=login&id=en%3Adevelopment%3Arfcs3.2 ?

(Together or separated, whichever seems best)

-- 
Jesse Weaver
Software Developer, LibLime
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20081011/52f41301/attachment-0002.htm>