Bug 25934 - [OMNIBUS] Passwords should be more complex / password policy complexity
Summary: [OMNIBUS] Passwords should be more complex / password policy complexity
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Authentication (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 32553 33042
Blocks:
  Show dependency treegraph
 
Reported: 2020-07-06 02:15 UTC by David Cook
Modified: 2023-02-22 17:00 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2020-07-06 02:15:22 UTC
At the moment, RequireStrongPassword uses a minimum password length (of only 3 characters or the sysperf minPasswordLength) and a static regular expression.

Here are a number of improvements:

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

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

3. Not be the same as a previously set password

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.)

5. Should not be equal to the username
Comment 1 Katrin Fischer 2020-07-06 05:55:24 UTC
There was discussion in the past about having some kind of plugin structure (bug 13664). 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.
Comment 2 David Cook 2020-07-06 06:14:15 UTC
(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.
Comment 3 Katrin Fischer 2020-07-06 06:24:57 UTC
I think a stronger default for new installations should be agreeable, but we can't change behaviour for existing ones.
Comment 4 George Williams (NEKLS) 2020-07-06 15:44:21 UTC
#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.
Comment 5 David Cook 2020-07-08 02:04:01 UTC
(In reply to Katrin Fischer from comment #3)
> I think a stronger default for new installations should be agreeable, but we
> can't change behaviour for existing ones.

That's a good point, although it would be good to force users to change their passwords after policy changes. So libraries with knowledgeable administrators could update their existing installations to more secure settings. 

(In reply to George Williams (NEKLS) from comment #4)

Those are interesting points. 

From my perspective as a vendor/sysadmin, I'd prefer to mandate strong security across the board to give the library the best protection. But from the library perspective, I can understand wanting flexibility. 

From the vendor perspective, so long as there isn't a bug that can compromise the underlying server, then I suppose the onus is on the library to manage their own application security settings.
Comment 6 Fred King 2020-07-08 16:44:59 UTC
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.

#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).

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

#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.")

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

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

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.
Comment 7 David Cook 2020-07-09 00:12:20 UTC
(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.
Comment 8 Marcel de Rooy 2020-07-29 07:24:58 UTC
Definitely, we should improve security in Koha. The requirements listed on top sound good to me. But as the comments show, they have more support base when we can configure such values. The defaults should be high imo.

Note that bug 18308 raised minPasswordlength to 8 for new installs already.
Comment 9 Katrin Fischer 2023-02-22 17:00:13 UTC
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".