September 2020 - Koha-bugs - lists.koha-community.org

[Bug 12617] Koha should let admins to configure automatically generated password complexity/difficulty
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '20

30 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12617 --- Comment #24 from David Cook <dcook(a)prosentient.com.au> --- One very last thing... Perl also has the Unicode::UCD module, which also allows us to interrogate the properties of Unicode characters without using regular expressions. (This would be more in the Java path I mentioned before.) You can read more at https://perldoc.pl/perluniprops. I reckon supporting Unicode for passwords isn't a bad thing. We support UTF-8 encoded characters throughout Koha, so may as well for the passwords, yes? It could also help users of Koha that use non-Latin alphabets, which would improve Koha usability globally. Final 2 cents ;). -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12617] Koha should let admins to configure automatically generated password complexity/difficulty
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '20

30 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12617 --- Comment #23 from David Cook <dcook(a)prosentient.com.au> --- I mention Keycloak as well, since Keycloak is actually an Angular app which uses Java for its backend. When I set a password policy and try to set a password that doesn't match it, I get a 400 error, so it's clearly sending the password to the backend for validation. We may want to do the same thing here so that we can centralize the password validation code in Perl (rather than trying to have equivalents in both Perl and Javascript). Note also that Perl has \p{} and \P{} constructs for matching Unicode properties. For example, \p{Uppercase}, although of course you could just use the [:upper:] POSIX construct instead. That said, it turns out that Javascript (unsure of versions) does have support for \p and \P in regular expressions as well..., so a person can do the following to check if a character is uppercase: function is_upper(value){ return /\p{Uppercase}/u.test(value); } Likewise to detect a "letter": function is_letter(value){ return /\p{Letter}/u.test(value); } This matches alphabetic characters as well as Chinese characters it appears. According to https://www.compart.com/en/unicode/U+6211, 我 is a member of the "Other Letter" category. Take a look at https://www.regular-expressions.info/unicode.html for a full list of Unicode categories. To get the equivalent of Java Character.isLetterOrDigit, we'd basically just need a regular expression like the following (the difference being that the following includes the Cased_Letter category too which is OK as it's already covered by Lowercase_Letter and Uppercase_Letter): (\p{Letter}|\p{Decimal_Digit_Number}). Going back to Javascript and browser compatibility: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expre… It looks like Unicode property escapes are supported in Javascript except for... "Internet Explorer" and "Firefox for Android". There is also a note about case folding for Edge, although I think that's for the pre-Chromium Edge. Anyway, again, just my 2 cents. It was interesting research/experiments, and hopefully it is useful. If not for this patch then at least other parts of Koha. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12617] Koha should let admins to configure automatically generated password complexity/difficulty
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '20

30 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12617 --- Comment #22 from David Cook <dcook(a)prosentient.com.au> --- Apologies if people find this uninteresting. Keycloak's LowerCasePasswordPolicyProvider.java file uses Java's Character.isLowerCase() function... Looking at OpenJDK 8... http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/dc4322602480/src/share/clas… That appears to use Unicode code points (as integers)... With CharacterData, it does some bit math to use some generated character class lookups it seems... https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java… It's a rabbit hole, but Java really does seem to be king when it comes to working with character data... Going back to Keycloak, SpecialCharsPasswordPolicyProvider.java seems to indicate that anything that doesn't return true for Character.isLetterOrDigit is a "special character". According to Java, "Not all letters have case. Many characters are letters but are neither uppercase nor lowercase nor titlecase". Interesting. Apparently that's in regards to the "Lo" "Other Letter" Unicode category (https://www.compart.com/en/unicode/category/Lo) with Arabic being one of the most obvious examples. And according to Java, "isLetter" is only uppercase letters, lowercase letters, title case letters, modifier letters, and other letters with "modifier letters" being the "Lm" category (https://www.compart.com/en/unicode/category/Lm) Java has an isIdeographic function for checking CJKV characters, but that seems to rely on a generated code point lookup table (although I haven't fully explored that path). -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12617] Koha should let admins to configure automatically generated password complexity/difficulty
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '20

30 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12617 --- Comment #21 from David Cook <dcook(a)prosentient.com.au> --- The following is incomplete but could be useful for testing individual characters (you'd just have to iterate through the password string). Tangentially, Chinese characters will pass both the "is_upper" and "is_lower" case tests. In terms of pam_cracklib, it seems that Chinese characters would give uppercase credits but not lowercase credits (since a character can only be classed with 1 class). Unfortunately, special characters also pass the "is_upper" and "is_lower" tests, so that algorithm isn't really good enough. THat said, C implementations for isupper is super problematic too as they're ASCII based... (https://git.musl-libc.org/cgit/musl/tree/include/ctype.h) But I guess that goes back to supporting ASCII-only passwords... <html> <head> <script> function is_upper(value){ var is_upper = false; if (value.toUpperCase() === value){ is_upper = true; } return is_upper; } function is_lower(value){ var is_lower = false; if (value.toLowerCase() === value){ is_lower = true; } return is_lower; } function is_digit(value){ return /\d/.test(value); } alert(is_lower('?')); /* alert(is_digit('A')); alert(is_digit('1')); alert(is_lower('我')); alert(is_lower('ä')); alert(is_lower('Ä')); */ </script> </head> </html> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12617] Koha should let admins to configure automatically generated password complexity/difficulty
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '20

30 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12617 --- Comment #20 from David Cook <dcook(a)prosentient.com.au> --- Ok because I'm insufferable... The following passes: <html> <head> <script> var min_lenght = 3; var regex_text = "(?=.*\\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#$%\^&*(){}[\\]<>?/|\-]).{"+min_lenght+",}"; var pattern_regex = new RegExp(regex_text); var output = pattern_regex.test("Aa1!"); alert(output); </script> </head> </html> The following fails: <html> <head> <script> var min_lenght = 3; var regex_text = "(?=.*\\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#$%\^&*(){}[\\]<>?/|\-]).{"+min_lenght+",}"; var pattern_regex = new RegExp(regex_text); var output = pattern_regex.test("Ää1!"); alert(output); </script> </head> </html> That's not good. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12617] Koha should let admins to configure automatically generated password complexity/difficulty
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '20

30 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12617 --- Comment #19 from David Cook <dcook(a)prosentient.com.au> --- Comment on attachment 110528 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=110528 Bug 12617: Add new regex patterns to password_check.inc Review of attachment 110528: --> (https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=126…) ----------------------------------------------------------------- ::: koha-tmpl/opac-tmpl/bootstrap/en/includes/password_check.inc @@ +13,5 @@ > > if(category_selector && $('select'+category_selector).length) { > jQuery.validator.addMethod("password_strong", function(value, element){ > var require_strong = $('select'+category_selector+' option:selected').data('pwdStrong'); > var min_lenght = $('select'+category_selector+' option:selected').data('pwdLength'); Btw this should be min_length, although it does look like you've used the misspelled variable consistently... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12617] Koha should let admins to configure automatically generated password complexity/difficulty
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '20

30 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12617 --- Comment #18 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Fridolin SOMERS from comment #16) > > However Javascript doesn't seem to support POSIX > Ah ok good point. > > But why are öäåÄÖÅ not in : > if ( password_policy == 'complex' ){ > chars = > '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ|[]{}! > @#$%^&*()_-+?'; > > In my opinion, for a heavy international software like Koha you may stick to > [a-zA-Z] as the only alphabetic characters. > > Or create lang-based policies complex-en, complex-fi ... Based on my earlier comment, especially regarding Red Hat's Keycloak password policies, I think that limiting to '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ|[]{}!@#$%^&*()_-+?' might not be wise for a "complex" policy. Look at pam_cracklib too which is used by massive international Linux providers (https://linux.die.net/man/8/pam_cracklib and https://github.com/linux-pam/linux-pam/blob/master/modules/pam_cracklib/pam…) There complexity is determined by "minlen, maxclassrepeat, dcredit, ucredit, lcredit, and ocredit". Looking at https://github.com/linux-pam/linux-pam/blob/master/modules/pam_cracklib/pam…, it looks like the ctype library includes functions for isupper, islower, isdigit, etc. "ocredit" for "other characters" is just whatever isn't a digit, uppercase letter, or lowercase letter. The Javascript would be more verbose, but it should be doable using a similar algorithm. Chinese is probably still an issue if your password policy has uppercase and lowercase requirements, but that's probably why there are so many Chinese ASCII passwords as per my previous post, but Latin characters with diacritics should be fine using this kind of complexity. But... that's just my 2 cents. I'm not the one writing this patch. I also haven't extensively tested it, so maybe I'm missing the current point of the conversaton. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12617] Koha should let admins to configure automatically generated password complexity/difficulty
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '20

30 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12617 --- Comment #17 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Fridolin SOMERS from comment #16) > > However Javascript doesn't seem to support POSIX > Ah ok good point. > > But why are öäåÄÖÅ not in : > if ( password_policy == 'complex' ){ > chars = > '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ|[]{}! > @#$%^&*()_-+?'; > > In my opinion, for a heavy international software like Koha you may stick to > [a-zA-Z] as the only alphabetic characters. > > Or create lang-based policies complex-en, complex-fi ... I think the default with password managers tend to be printable ASCII characters (ie: Upper-case, Lower-case, Digits, Special). That said, I have seen "High ANSI characters" as an option... But then I thought about Chinese password habits (https://medium.com/@ye.sunnia/an-analysis-of-chinese-passwords-e49b97b91919 or https://www.theverge.com/tldr/2019/3/5/18252150/bad-password-security-data-…) which seem to fall into ASCII. I just spun up a Keycloak container (an Identity Provider created by Red Hat), and I'm trying to reset my password (as a user) to a Chinese password in Windows Chrome, but it seems to be preventing my software-based pinyin input from working. It seems to be forcing my hardware keyboard. (Like if I type in "wo", I see 2 masked characters appearing in the password field, rather than being able to select the 1 我 character.) That said, as a Keycloak admin, I was able to input a 我 character into the user's password field. I wasn't able to manually enter it as a user, but if I copied and pasted 我 into the password field as a user, it worked. Going back to the user view, I notice when I move from the username field to the password field, my software keyboard changes modes from Chinese mode to English mode. If manually change the mode... it doesn't seem to make a difference. Here's some reading on Keycloak password policies: https://www.keycloak.org/docs/latest/server_admin/#password-policy-types, which might be useful. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 26575] New: "New child record" doesn't know about 264 (RDA) yet
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '20

29 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26575 Bug ID: 26575 Summary: "New child record" doesn't know about 264 (RDA) yet Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When there is no 260 in the record, we should also check for information in 264 and use this instead when creating a new record using the "New child record" functionality. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 26574] New: Cataloging plugin marc21_linking_section.pl doesn't support 264 (RDA) yet
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '20

29 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26574 Bug ID: 26574 Summary: Cataloging plugin marc21_linking_section.pl doesn't support 264 (RDA) yet Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The cataloguing plugin marc21_linking_section.pl doesn't support 264 yet, but only copies information from 260. We should check for 264 when 260 is not found. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0