From Agnes Rivers-Moore on bug 21190: Ah - there might be a problem with Koha counting SIP logins as 'failed' attempts. I could not see it before, but thanks to this enhancement I do see that the total of login attempts goes up by one when I log in to Overdrive Libby, and it is not reset to zero again - even though the login is successful. We had found more patrons complained of being locked out of the OPAC when they had not had 8 failed login attempts. If SIP login adds one every time, and does not clear back to zero, people using SIP products can come back to the Koha OPAC and find themselves locked out. I am on Koha 20.11 It may be this needs to be a separate new bug - anyone interested to describe what's not working as expected with SIP logins? (and possibly other kinds of external login too...)
ILS/Patron.pm:sub check_password { ILS/Patron.pod: $str = $patron->check_password($password); ILS/Patron.pod:=head2 C<$bool = $patron-E<gt>check_password($password);> Sip/MsgType.pm: $password_rc = $patron->check_password($patron_pwd); Sip/MsgType.pm: $resp .= add_field( FID_VALID_PATRON_PWD, sipbool( $patron->check_password( $fields->{ (FID_PATRON_PWD) } ) ), $server ); Sip/MsgType.pm: $password_rc = $patron->check_password($patron_pwd); Sip/MsgType.pm: if ( !defined($patron_pwd) || $patron->check_password($patron_pwd) ) { Sip/MsgType.pm: $resp .= add_field( FID_VALID_PATRON_PWD, sipbool( $patron->check_password($patron_pwd) ), $server ); build patron status handle checkout handle_patron_info handle_patron_enable CALLED twice
Kyle or Nick, Does 27600 address this? That one refers to renewal. I have the idea that this one might be more? Does it depend on Overdrive ?
(In reply to Marcel de Rooy from comment #2) > Kyle or Nick, > Does 27600 address this? That one refers to renewal. > I have the idea that this one might be more? > Does it depend on Overdrive ? It does not address this, just a related issue with the call to check_password
I think this may apply to all external online services that check with Koha through SIP for patron status. Probably does not apply to self-serve checkout through SIP as I think people log out again after checking out, but I have not tested and am not sure. Sad to see this considered LOW importance, as it is a major failure for the many patrons we have who use our online services (ebooks, video, magazines), then frequently and repeatedly have to ask staff to reset their password through no fault of theirs. Please reconsider.
Hi Agnes, we don't use the first importance field actively - low is just the default and you can ignore it. (I think we cannot hide it :( ) The second category 'normal' is what we are actually using.
I am updating to 'major' to get more attention on this. FailedLoginAttempts should be a recommended security measure to avoid brute force attacks on patron accounts and if I understand it correctly, this bug will prevent libraries with self checks (some require login) etc. from using it.
I cannot recreate using sip_cli_emulator with a checkout. Marcel, did you manage to recreate the problem?
(In reply to Jonathan Druart from comment #7) > I cannot recreate using sip_cli_emulator with a checkout. > > Marcel, did you manage to recreate the problem? No. Will try later this week.
We are seeing this often but it's not from a checkout - it is from logging in to a remote 3rd party service that uses SIP to check the borrower status. In my example - Overdrive - the Koha member logs in to access their account in Overdrive, Overdrive queries Koha with SIP to check the member patron record is not expired or suspended. There is no checkout process associated with Koha, but somehow that gets recorded as a login attempt (either an unsuccessful one, or one not cancelled by a log out). Overdrive checkout then proceeds in the Overdrive member account. The same may be happening with other third party SIP connections that check status. To recreate - set up Overdrive to confirm members status using SIP. Create a Koha account. Create an Overdrive account using the member barcode. Log in to Libby using the patron barcode. In Koha, check the current logins = 1. Log out of Libby, login count in Koha remains at 1. Log in to Libby - check login count increases to 2. I hope I have explained clearly. We do want the SIP logins to be registered in Koha - there was a bug/enhancement about that as there was no record of 'last seen' in Koha from those external SIP transactions. That was worked on, so that the last seen would update for external SIP logins.
(In reply to Agnes Rivers-Moore from comment #9) > We are seeing this often but it's not from a checkout - it is from logging > in to a remote 3rd party service that uses SIP to check the borrower status. > In my example - Overdrive - the Koha member logs in to access their account > in Overdrive, Overdrive queries Koha with SIP to check the member patron > record is not expired or suspended. There is no checkout process associated > with Koha, but somehow that gets recorded as a login attempt (either an > unsuccessful one, or one not cancelled by a log out). Overdrive checkout > then proceeds in the Overdrive member account. The same may be happening > with other third party SIP connections that check status. To recreate - set > up Overdrive to confirm members status using SIP. Create a Koha account. > Create an Overdrive account using the member barcode. Log in to Libby using > the patron barcode. In Koha, check the current logins = 1. Log out of Libby, > login count in Koha remains at 1. Log in to Libby - check login count > increases to 2. I hope I have explained clearly. > We do want the SIP logins to be registered in Koha - there was a > bug/enhancement about that as there was no record of 'last seen' in Koha > from those external SIP transactions. That was worked on, so that the last > seen would update for external SIP logins. Looks like you need someone who knows these third party tools. What I do see in the Koha code, is that patron_status and patron_info requests when accompanied by a patron password will lead to a verification that might increase login_attempts when it is wrong. Note that patron_info does not need it to provide output. In other words: Does Overdrive perhaps send a empty password string for a patron info request?
(In reply to Marcel de Rooy from comment #10) > Looks like you need someone who knows these third party tools. > What I do see in the Koha code, is that patron_status and patron_info > requests when accompanied by a patron password will lead to a verification > that might increase login_attempts when it is wrong. Note that patron_info > does not need it to provide output. > In other words: Does Overdrive perhaps send a empty password string for a > patron info request? It can, this is configured per site with OverDrive There is a SIP configuration setting: allow_empty_passwords If that is set the login_attempts must not be incremented on an empty password
(In reply to Nick Clemens from comment #11) > There is a SIP configuration setting: allow_empty_passwords Good catch Nick. So this is certainly a duplicate of bug 21997.
Does the patron_info sub actually need this SIPconfig setting? Or should we just not verify an empty string here?
(In reply to Jonathan Druart from comment #12) > (In reply to Nick Clemens from comment #11) > > There is a SIP configuration setting: allow_empty_passwords > > Good catch Nick. So this is certainly a duplicate of bug 21997. Well, we are on 20.11.09 - so if it was fixed it broke again, or this is not exactly the same issue.
(In reply to Agnes Rivers-Moore from comment #14) > (In reply to Jonathan Druart from comment #12) > > (In reply to Nick Clemens from comment #11) > > > There is a SIP configuration setting: allow_empty_passwords > > > > Good catch Nick. So this is certainly a duplicate of bug 21997. > > Well, we are on 20.11.09 - so if it was fixed it broke again, or this is not > exactly the same issue. Do you have allow_empty_passwords turned on in the config?
(In reply to Jonathan Druart from comment #12) > (In reply to Nick Clemens from comment #11) > > There is a SIP configuration setting: allow_empty_passwords > > Good catch Nick. So this is certainly a duplicate of bug 21997. Well, we are on 20.11.09 - so if it was fixed it broke again, or this is not exactly the same issue. (In reply to Jonathan Druart from comment #15) > (In reply to Agnes Rivers-Moore from comment #14) > > (In reply to Jonathan Druart from comment #12) > > > (In reply to Nick Clemens from comment #11) > > > > There is a SIP configuration setting: allow_empty_passwords > > > > > > Good catch Nick. So this is certainly a duplicate of bug 21997. > > > > Well, we are on 20.11.09 - so if it was fixed it broke again, or this is not > > exactly the same issue. > > Do you have allow_empty_passwords turned on in the config? In Administration - Enhanced Content I see a pref for Overdrive specifically that says A password is NOT REQUIRED for user access to OverDrive. In config - I do not know, is that on the back end? I can ask Equinox. Would it not take the setting from the Administration Pref?
(In reply to Agnes Rivers-Moore from comment #16) > In Administration - Enhanced Content I see a pref for Overdrive specifically > that says A password is NOT REQUIRED for user access to OverDrive. > In config - I do not know, is that on the back end? I can ask Equinox. Would > it not take the setting from the Administration Pref? That setting is related to OverDrive checkouts - it does not change what overdrive sends, but simply whether Koha asks the user for their password when logging them in to Koha - so it is a setting you determine with OverDrive when setting up access
I can confirm, setting: allow_empty_passwords="1" in SIP config will eliminate the issue You can test on kohadevbox using telnet: apt install telnet telnet localhost 6001 9300CNterm1|COterm1|CPCPL| 6300120211018 150348 AOCPL|AA23529000035676|ACterm1|AD| Without allow_empty_passwords an empty string is checked and login_attempts incremeneted With it, login attempts are not You can see in the response: |AFGreetings from Koha. -- Invalid password| if the setting is not enabled Agnes: You should either ask Equinox to change the setting for you, or ask OverDrive to send/require passwords if you would rather go that way. Otherwise, I believe this is working correctly
Thank you Nick. Just curious what the function of the Admin Preference is if it does not relate to the SIP setup?
Ooops, didn't see your earlier explanation .I get it now - and we don't have Overdrive checkout turnedon so I guess for us it has no effect.
(In reply to Nick Clemens from comment #18) > I can confirm, setting: > allow_empty_passwords="1" > in SIP config will eliminate the issue > > You can test on kohadevbox using telnet: > apt install telnet > telnet localhost 6001 > 9300CNterm1|COterm1|CPCPL| > 6300120211018 150348 AOCPL|AA23529000035676|ACterm1|AD| > > > Without allow_empty_passwords an empty string is checked and login_attempts > incremeneted > With it, login attempts are not > > You can see in the response: > |AFGreetings from Koha. -- Invalid password| > if the setting is not enabled > > Agnes: You should either ask Equinox to change the setting for you, or ask > OverDrive to send/require passwords if you would rather go that way. > > Otherwise, I believe this is working correctly
(In reply to Katrin Fischer from comment #21) > (In reply to Nick Clemens from comment #18) > > I can confirm, setting: > > allow_empty_passwords="1" > > in SIP config will eliminate the issue > > > > You can test on kohadevbox using telnet: > > apt install telnet > > telnet localhost 6001 > > 9300CNterm1|COterm1|CPCPL| > > 6300120211018 150348 AOCPL|AA23529000035676|ACterm1|AD| > > > > > > Without allow_empty_passwords an empty string is checked and login_attempts > > incremeneted > > With it, login attempts are not > > > > You can see in the response: > > |AFGreetings from Koha. -- Invalid password| > > if the setting is not enabled > > > > Agnes: You should either ask Equinox to change the setting for you, or ask > > OverDrive to send/require passwords if you would rather go that way. > > > > Otherwise, I believe this is working correctly This was resolved for us by correcting that back-end setting allow_empty_passwords.