Re: [Koha] SIP2 AF field sent even if patron password is invalid
I think the essential problem is SIP has two levels of authentication. The SIP server level, then the patron level. I think the SIP protocol intends for the SIP client to behave responsibly with the data it gets, but in reality SIP device manufacturers don't seem to try very hard. For instance, what if we had a system with users that would periodically mine a SIP2 server for data? Let's say it's a university system that needs to know if a student owes the library money and they can't graduate without paying off any money owed to the library. In this case, SIP2 must be able to supply all the data even without knowing the patron's password. As far as I can tell, the SIP2 spec does not intend a bad user password to limit any data, it up to the client to determine what and what not to display given a bad patron password. But, since we can't strong arm SIP2 device manufacturers into using SIP2 properly, we need to deal with this ourselves. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Wed, Jul 30, 2014 at 10:03 AM, Aaron Sakovich <asakovich@hmcpl.org> wrote:
Hi,
I'm also concerned about the wealth of other info returned if an invalid password is provided. I just tried sending a bad password and got the following info returned from Koha:
64 00120140730 084016000000000000000000000000AOMAIN|AA21562006551554|AESpunky Tester|BLY|CQN|CC15.00|BD915 Monroe Street Huntsville AL 35801 Madison| BEaarons@hmcpl.org|PB
AE: full name CQ: password verification failed! BD: street address BE: email address
I did not see the AF field returned. However, someone with nefarious intent could harvest a LOT of patron info from SIP by just randomly (or sequentially) throwing out guessed library card numbers. Shouldn't the only thing returned be a CQN? (NB: we're on 3.14)
Aaron -- Aaron Sakovich Internet and Technology Services manager Huntsville-Madison County Public Library http://hmcpl.org/ -- asakovich@hmcpl.org
On Jul 29, 2014, at 10:35 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
I have an interesting SIP2 implementation issue. When authenticating through SIP2, if a valid patron id is passed in, but an *invalid* password is passed in, Koha's SIP2 server send back the AF ( screen message ) field even though the credentials are invalid. If a patron owes any fees, the server will send back the amount owed in an AF field.
For instance, Overdrive will display this AF field even with an invalid password. Freegal does not ( but it may not display any AF field ). At least one SIP2 machine we tested against will also display the AF field when an invalid password is submitted.
Is this a Koha issue, or a client side issue? The SIP2 protocol specification does not indicate that AF fields should be removed in the event of an invalid password. My guess is that some SIP2 server implementations may send back "Invalid password" messages which may be useful.
Kyle
http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Thu, Jul 31, 2014 at 07:25:49AM -0400, Kyle Hall wrote:
As far as I can tell, the SIP2 spec does not intend a bad user password to limit any data, it up to the client to determine what and what not to display given a bad patron password.
Many of the early sip devices considered the fact a user had wanded a barcode, security enough. I recall machines which sent blank passwords meaning 'I dont care about passwords and if they're valid'. The implication of the standard is that the client end will do the right thing if I flag up the password was invalid. NB that responses like patron status return both whether the patron is valid and whether the password is valid which suggests that the two are independent and it may want info back irrespective of password validity. Its also not impossible that a client application may want patron data and issue an info request without that patron being present (whether such an app should be tolerated is another thing). So I think we should certainly tailor message resonses sensibly but policy is the responsibility of the client device. (maybe we should look a bit closer at them) C. -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 800 756 6803 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com
Hi, On Thu, Jul 31, 2014 at 9:21 AM, Colin Campbell <colin.campbell@ptfs-europe.com> wrote:
Many of the early sip devices considered the fact a user had wanded a barcode, security enough. I recall machines which sent blank passwords meaning 'I dont care about passwords and if they're valid'. The implication of the standard is that the client end will do the right thing if I flag up the password was invalid.
It wouldn't surprise me if this were the case back then, but yesterday's trusting serial line protocol is today's remote exposure of sensitive patron information breach.
NB that responses like patron status return both whether the patron is valid and whether the password is valid which suggests that the two are independent and it may want info back irrespective of password validity. Its also not impossible that a client application may want patron data and issue an info request without that patron being present (whether such an app should be tolerated is another thing). So I think we should certainly tailor message resonses sensibly but policy is the responsibility of the client device. (maybe we should look a bit closer at them)
I agree that it will be necessary to tailor responses per client, but I do think that the default should be to limit what gets disclosed if an invalid patron password is presented, as information disclosure policies is necessarily the responsibility of the SIP2 server. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Hi, In my experience not all libraries require a password or PIN at the self check station. One of the reasons can be that the self check used doesn't have a full keyboard but only a number pad and we can't limit passwords in Koha to be only numeric. So keeping the option to work without passwords would be good.
On Thu, Jul 31, 2014 at 9:21 AM, Colin Campbell <colin.campbell@ptfs-europe.com> wrote:
Many of the early sip devices considered the fact a user had wanded a barcode, security enough. I recall machines which sent blank passwords meaning 'I dont care about passwords and if they're valid'. The implication of the standard is that the client end will do the right thing if I flag up the password was invalid.
It wouldn't surprise me if this were the case back then, but yesterday's trusting serial line protocol is today's remote exposure of sensitive patron information breach.
NB that responses like patron status return both whether the patron is valid and whether the password is valid which suggests that the two are independent and it may want info back irrespective of password validity. Its also not impossible that a client application may want patron data and issue an info request without that patron being present (whether such an app should be tolerated is another thing). So I think we should certainly tailor message resonses sensibly but policy is the responsibility of the client device. (maybe we should look a bit closer at them)
I agree that it will be necessary to tailor responses per client, but I do think that the default should be to limit what gets disclosed if an invalid patron password is presented, as information disclosure policies is necessarily the responsibility of the SIP2 server.
I agree that we shouldn't send patron information if a wrong password was provided. Maybe it could be a configuration switch that defines if passwords are expected and react accordingly? Regards, Katrin
I second that opinion Katrin. Requiring a pin would be problematic for our self-checkout patrons as well. Forgetting pin #'s, changing their telephone #'s, (we use the last 4 digits of the patron's phone # for our OPAC passwords), etc., would be a giant hassle for out circulation staff, if pins were required for self-check. Put me down as a big NO THANK YOU for requiring pin numbers at checkout, if that's what we are talking about. Scott Kushner Systems Librarian Middletown Public Library 55 New Monmouth Rd Middletown, NJ 07748 -----Original Message----- From: Koha [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Katrin Fischer Sent: Saturday, August 02, 2014 8:32 AM To: koha@lists.katipo.co.nz Subject: Re: [Koha] SIP2 AF field sent even if patron password is invalid Hi, In my experience not all libraries require a password or PIN at the self check station. One of the reasons can be that the self check used doesn't have a full keyboard but only a number pad and we can't limit passwords in Koha to be only numeric. So keeping the option to work without passwords would be good.
On Thu, Jul 31, 2014 at 9:21 AM, Colin Campbell <colin.campbell@ptfs-europe.com> wrote:
Many of the early sip devices considered the fact a user had wanded a barcode, security enough. I recall machines which sent blank passwords meaning 'I dont care about passwords and if they're valid'. The implication of the standard is that the client end will do the right thing if I flag up the password was invalid.
It wouldn't surprise me if this were the case back then, but yesterday's trusting serial line protocol is today's remote exposure of sensitive patron information breach.
NB that responses like patron status return both whether the patron is valid and whether the password is valid which suggests that the two are independent and it may want info back irrespective of password validity. Its also not impossible that a client application may want patron data and issue an info request without that patron being present (whether such an app should be tolerated is another thing). So I think we should certainly tailor message resonses sensibly but policy is the responsibility of the client device. (maybe we should look a bit closer at them)
I agree that it will be necessary to tailor responses per client, but I do think that the default should be to limit what gets disclosed if an invalid patron password is presented, as information disclosure policies is necessarily the responsibility of the SIP2 server.
I agree that we shouldn't send patron information if a wrong password was provided. Maybe it could be a configuration switch that defines if passwords are expected and react accordingly? Regards, Katrin _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Hi, On Tue, Aug 5, 2014 at 1:49 PM, Scott Kushner <skushner@mplmain.mtpl.org> wrote:
Put me down as a big NO THANK YOU for requiring pin numbers at checkout, if that's what we are talking about.
It isn't, at least not quite. One of the things being proposed is that *if* the SIP2 device supplies a patron password/PIN that is incorrect, there should be an option for the SIP server to refuse to return any information about the patron, in order to prevent systems that use SIP2 purely for authentication to permit leaking information to people who are not entitled to it. The emphasis is on the word *option*, as other participants in this thread have identified various use cases where a device is using SIP2 for patron lookup, not authentication. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
participants (5)
-
Colin Campbell -
Galen Charlton -
Katrin Fischer -
Kyle Hall -
Scott Kushner