https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25934 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |dcook@prosentient.com.au |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25934 --- Comment #2 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #1)

There was discussion in the past about having some kind of plugin structure (bug 13664).

I was thinking about that a little bit. I mean password managers let you set length and character sets, so it does make sense for it to be a bit configurable. The dictionaries/common passwords would need to be configurable too. I think storing old password hashes and not matching username/password should just be baked in.

I think 1. might not be agreeable to some (unless you mean it would only enforce length in combination with another setting). There were libraries very much insisting on such short passwords.

That's unfortunate although that's a good point. Personally, I'd like strong defaults, and then people who choose weaker policies would have to accept the risk that brings. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25934 George Williams (NEKLS) <george@nekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |george@nekls.org --- Comment #4 from George Williams (NEKLS) <george@nekls.org> --- #1 - I completely disagree with #1. Why should we have a patch that will inevitably force libraries to change their password policies without giving them any choice in the matter? Koha gives libraries the flexibility to set their own policies and this would take that flexibility away. I agree that a 3 character minimum password is a bad idea, but I don't think that the Koha community should be forcing libraries from implementing bad ideas. I'm sure there are instances were, in the right circumstances, short passwords make sense for the libraries that are using them. #2 - Bug 12617 would allow individual Koha libraries to define password complexity on a patron-category-by-patron-category basis. I'd rather see work proceed on that bug than force system-wide password complexity for all accounts. #3 - I could get behind this if it can be implemented on a patron-category-by-patron-category basis. After the work is completed on bug 23816, that was something I was considering proposing as a development (along with forcing password changes after XX days on a patron-category-by-patron-category basis). #4 - This should be optional. If Bug 12617 was patched, that would address this issue, wouldn't it? #5 - I can get behind this one. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25934 koha-US bug tracker <bugzilla@koha-us.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla@koha-us.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25934 --- Comment #7 from David Cook <dcook@prosentient.com.au> --- (In reply to Fred King from comment #6)

While I agree that your password criteria would be useful for many Koha institutions, they would not be for all of them. My Koha system used to be behind my institution's firewall, and we didn't need such strict security. I had to move it to a cloud server so all our staff could access it while they worked from home, but I think that for us, your proposed changes would be far too strict.

Nothing would change for existing installs - only new ones. New installs could turn off the enhanced security.

#1: That's a lot of characters to remember. I work in a hospital where medical staff have access to extremely confidential information. Our minimum is eight characters. Even then, I usually end up writing mine down (in transliterated Cyrillic, so I think I'm minimizing the danger).

Encrypted password managers can be good for this. Although if a person doesn't have a dedicated workstation (like in a clinic), this can admittedly be problematic, but that really points to a problem with hospital computer security practices. But this problem can also be ameliorated by the use of Single Sign On to reduce the number of different passwords, and to make it easier to update passwords.

#2: See https://xkcd.com/936/. I think he has a good point.

There's been lots of online debate about this, but a person could do worse.

#3: This one I agree with. I'd also recommend a minimum number of days before you can change it again, if you're considering letting people reuse passwords after x number of changes. ("Time to change my password, and I can't use my past three passwords. Well, I'll change it to cat, then owl, then cow, and then back to dog.")

Yeah, in practice I find people often just increment a number at the end of the password to try to workaround this requirement. Users have shown me all kinds of very similar systems that they thought were unique/difficult to crack.

#4: Also challenging to low-spec systems that use more than one language. I'd really, really urge you to make this one optional.

Yeah, this one is really a "nice to have" rather than a must have. Even in a default situation, I wouldn't enable this because there are too many variables.

#5: Well, it's really useful on an in-house test system, but OK.

That makes me think about all those airplanes that have the same usernames and passwords from when they were on the in-house test system though.

I'm all in favor of protection, and I know full well that any online system can be attacked from anywhere. I'd just like the option to choose how many bars to put on the windows.

It's true. Koha is all about choice. I'll keep that in mind once I start on this work. It's great getting all these different perspectives. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25934 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=12617 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25934 Emmi Takkinen <emmi.takkinen@outlook.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emmi.takkinen@outlook.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25934 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=21314 Summary|RequireStrongPassword |[OMNIBUS] Passwords should |should be more complex |be more complex / password |(password policy |policy complexity |complexity) | Depends on| |32553, 33042 --- Comment #9 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- It feels like we should revisit this one. I think David made a lot of good suggestions, but maybe we should implement some of them as separate features:

1. A minimum length of 10 characters that can't be lowered via minPasswordLength

I think that would be an 'enhancement' of minPasswordLength. Maybe 8 would be more agreeable as a start (at the moment it's 3). But see also: bug 21314 that had an issue with 3 already.

2. Should contain 3 of the following 4 sets (lowercase, uppercase, numbers, special characters)

I think this could be a new second option to RequireStrongPassword if we restructured the code a bit to make it not boolean but have several password policies people can "update" to. I've filed: Bug 33042 - Enforce 4 character groups (lowercase, uppercase, numbers and special characters) in passwords

3. Not be the same as a previously set password

We have a separate bug for this already: Bug 32553 - Don't allow to use the same password as before when a password expires/is reset

4. Should not include dictionary words or common passwords (This could be challenging to do comprehensively on low spec systems, although one variation of this could be to add a customizable list of passwords to exclude.)

We could file a new report for this. I a not sure if there are existing multi-language dictionaries we could use here, but Koha being international might add some additional difficulty? 5. Should not be equal to the username That one could be a new pref..., but I feel like we should just "do it". Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32553 [Bug 32553] Don't allow to use the same password as before when a password expires/is reset https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33042 [Bug 33042] Enforce 4 character groups (lowercase, uppercase, numbers and special characters) in passwords -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.