On Wed, Oct 8, 2008 at 3:49 AM, Krishnan Mani <[EMAIL PROTECTED]> 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@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
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
