pam_faillock default of deny=3 is too stringent

[intentionally-left-nil]

I created #419 to change the default to, say 20.

Three failed passwords in the window is so incredibly easy to do, especially with a complicated password, or with multiple keyboard layouts.

Here are some downstream examples of people complaining about the default: https://bugs.archlinux.org/task/67644

[ldv-alt]

Looks like the main point of complains in the Arch Linux bug report is not that 3 is too stringent default for deny= option, but that the default action of denying access for a period of time is too stringent.
Unfortunately, the defaults cannot make everybody happy, but, fortunately, pam_faillock is configurable.

[intentionally-left-nil]

I think it can be both - the threshold for lockout is too low and the action taken is not proportionate.
From a user's perspective, I think it is quite often possible to mistype a password 3 times within the window.
As an personal anecdote, if I have my keyboard layout switched to the wrong layout, then my first password will be incorrect. Usually I think it's a typo so I'll try typing it in again.

Then when it doesn't work, I would realize it's in the wrong layout and switch. Now I only have one attempt to log in correctly.

I can think of many other cases when users would have difficulties - such as using a touch keyboard, having caps-lock pressed etc.

For some back-of-the-napkin math: If 5% of keystrokes have a chance of being wrong AND you not noticing, then you end up with a 10% chance of being locked out: (1 - (0.95 ^ 12)) ^3

a 98% accuracy would give you a lockout rate of 1%, or several times a year.

Compare that to changing the default to 20 attempts. You would end up with being locked out accidentally ~ 0 times a year (1 -(0.95 ^ 12)) ^20

From a security perspective, even for something like a 4 digit pin, changing the lockout from 3 -> 20 would mean that you have
3 / 10,000 chance of guessing the right number (e.g. 0.03% chance). Changing that to a threshold of 20 would mean a probability of 0.2%. And that's with a 4 digit pin (again back of the napkin, ignoring things like unequal password distribution)

TL;DR: I think there's a strong case to be made for raising the threshold to something larger.

[notlesh]

Learning a new password, new keyboard layout, switching keyboards, etc. will all lead to a high probability of triggering 3 failures within a short window.

[t8m]

Why the Arch Linux distro can ship a PAM configuration with pam_faillock set up by default but they cannot ship a faillock.conf file that would change the default to 20?
IMO there is no point in changing the default when it can be easily configured to a different value by the distro or by the sysadmin?

[intentionally-left-nil]

The reason for changing the default is that it's causing pain for users. I've made an argument why I think that 3 is a bad, real-life default. I think the best discourse here would be to figure out the following question, and from there we can find the right place for a solution.

Question: Is the default of 3 a "good" default for pam_faillock?
Possible Answers:

• Yes - and here are some reasons why
• Sometimes - and here are some reasons why - and if you don't like it then change the .conf
• No - and here are some reasons why.

In my previous post, I gave my answers (subjective & objective) for the "No" bucket.

I'd love to hear from you, or other folks a rationale for a different answer. We can come to an agreement on the nature of the problem and then move to the correct solution from there.

Thanks!

[t8m]

My answer: Sometimes and if you don't like it then change the .conf

The reason(s): The built-in default is just this - a built-in default. It does not mean that it needs to satisfy all use-cases. One of the use cases - the one that it was initially written for is compliance with Common Criteria certification rules. There the defaults are adequate as the security requirements in CC are at quite paranoid level. And yes, these defaults do not make much sense for regular workstation installations but there most probably the pam_faillock does not make sense to be placed in the default PAM stack configuration at all.

[hollunder]

For a year now I wondered why my sudo pw was not accepted even though it was correct. Just yesterday it happened to me on the initial login and was only fixed after power cycling. I thought my system is seriously broken.
This is an absolutely stupid change of defaults.

[notlesh]

it was initially written for is compliance with Common Criteria certification rules.

That's a compelling reason, but it serves a very small minority of users. Is there perhaps a way to make this work for CC certification but not be such a nuisance?

For a year now I wondered why my sudo pw was not accepted even though it was correct. Just yesterday it happened to me on the initial login and was only fixed after power cycling. I thought my system is seriously broken. This is an absolutely stupid change of defaults.

I actually thought something was horribly broken for a while as well.

One of the problems is that, when using SSH or sudo, you don't actually get any meaningful error message. The UX is indistinguishable from just typing the wrong password (or any number of other symptoms, like logging into the wrong machine, using the wrong kb layout, etc. etc. etc.). It wasn't until I tried logging in via getty that I saw a useful error message.

I suspect the answer is "that's downstream's problem," but is there a way we could improve the error message when this happens?

[t8m]

There was no change in defaults for pam_faillock! That Arch Linux decided to put pam_faillock as a module that is present by default in the configuration and not change the default either by patching the code or providing a default config file with some settings that would be more reasonable for general use cases, is their fault! I am going to close this issue.

[traverseda]

Generally the arch policy is to try and modify upstream as little as possible. I think that's a very good policy, presuming that the upstream developers are committed to setting up sane defaults.

Now I'm not sure that pam is intended to ship with faillock enabled by default. Is it? Do you (the maintainers of pam) think that faillock should be enabled by default? That it should be enabled with those defaults by default?

Because if you don't having you say that will actually go a long way towards getting the arch linux team to not include it by default, they do respect upstream and how upstream intends the packages to be used. If you could clarify when you think it's appropriate to use faillock, and what some appropriate defaults would be for it, I think a lot of users would appreciate it.

Personally this problem has been a problem for me off and on for a while, but I didn't care enough to track it down to this issue until I switched to a new laptop a few days ago, one with a subtly different keyboard layout. Obviously I've fixed the issue on my laptop but I think it would save a lot of people a lot of frustration if we could get either some better defaults or possibly a more descriptive error message when it happens? It will b e a lot easier to convince the arch team to set up better defaults if the maintainers of this package can issue some kind of unofficial statement.

[polarathene]

Summary of verbose response:

• As defaults are subject to change... deny = 3 as a default (justified to satisfy paranoid levels of compliance) seems odd? Any security audit that relies on that is likely to mandate explicit configuration anyway?
• Unless the majority of deployments where pam_faillock is intended to be used must comply with CC rules, and the default is somehow required to be certified for such - adjusting the default to suit the majority of use-cases where pam_faillock is useful would be appreciated.
• There are numerous scenarios where deny = 3 is problematic - especially when the user is not a security professional and trusts the maintainers to know what is most appropriate.
• The docs for the module do not clarify that the configuration defaults (and example config shown) are tailored to paranoid levels, nor that the module is discouraged for systems running a desktop environment.

If adjusting the default value for deny is out of the question... Could you at least be open to improving the modules docs?:

• At least with a statement about when the module is suitable (or not).
• What the defaults and example config are intended for (alternatively an example that is suitable for non-paranoid contexts, such as desktop/workstation systems).

---

Verbose response

The reason(s): The built-in default is just this - a built-in default. It does not mean that it needs to satisfy all use-cases.

👍 That is very true. But I think we can agree that defaults ideally are sane/good for the general use-cases that it supports? (and can usually be revised to a more appropriate default when it makes sense to?)

linux-pam/modules/pam_faillock/faillock.conf

Lines 29 to 32 in 510e825

	# Deny access if the number of consecutive authentication failures
	# for this user during the recent interval exceeds n tries.
	# The default is 3.
	# deny = 3

One of the use cases - the one that it was initially written for is compliance with Common Criteria certification rules.
There the defaults are adequate as the security requirements in CC are at quite paranoid level.
And yes, these defaults do not make much sense for regular workstation installations

Does that certification require a default to meet compliance? Or just that it is configurable to meet compliance?

I would assume that in security contexts, it's important that the admin knows how to configure a system properly to meet any compliance requirements. Would they trust defaults implicitly? Would they be opposed to pam_faillock having a higher deny default?

Contrast that to other use-cases of pam_faillock, who benefits the most from practical defaults where pam_faillock can be useful?

In the case of Arch, they try to minimize adding any custom configuration by trusting the defaults from upstream where possible. There are no alternative editions catering specifcally for server or desktop users, and like the policy to respect the default configs, this is something users of Arch generally prefer (assuming upstream has sane defaults).

---

I am curious if the majority of deployments with pam_faillock would be actually need to comply with Common Criteria rules, and expect such compliance be provided by default configs with all software, rather than expecting to be configured for paranoid levels explicitly when necessary?

---

That Arch Linux decided to put pam_faillock as a module that is present by default in the configuration and not change the default either by patching the code or providing a default config file with some settings that would be more reasonable for general use cases, is their fault!

I think in all fairness, Arch maintainers trusted your defaults to be sane (tailored for the majority of use-cases pam_faillock was intended for), not for paranoid level of compliance as you mentioned.

Your docs for the module also provide a similar example with very low deny:

linux-pam/modules/pam_faillock/faillock.conf.5.xml

Lines 201 to 223 in 510e825

	<refsect1 id='faillock.conf-examples'>
	<title>EXAMPLES</title>
	<para>
	/etc/security/faillock.conf file example:
	</para>
	<programlisting>
	deny=4
	unlock_time=1200
	silent
	</programlisting>
	</refsect1>
	<refsect1 id="faillock.conf-files">
	<title>FILES</title>
	<variablelist>
	<varlistentry>
	<term><filename>/etc/security/faillock.conf</filename></term>
	<listitem>
	<para>the config file for custom options</para>
	</listitem>
	</varlistentry>
	</variablelist>
	</refsect1>

No where in these docs have you implied that these defaults are aimed at meeting "Common Criteria rules" for compliance at paranoid levels.

Would it not be better to provide an example config (or alternatively an explicit statement against using the module) regarding what maintainers of the module consider suitable for workstation use?

Hopefully that's not too much to ask (better communication), especially when it comes to security focused projects, often users (and this perhaps includes maintainers of Arch too) will trust the experts upstream to know what is best unless advising users otherwise.

Whereas security professionals likely know better and know how to configure software for their security requirements, especially when they have compliance requirements to meet. It seems to be the wrong demographic to bias defaults to, unless absolutely required to meet that compliance (seems unlikely since you advise downstream to adjust defaults, and a deployment may inherit those instead, requiring configuration anyway, at least in awareness and to check/verify the default).

Additionally, as defaults can be subject to change...for compliance reasons I can only imagine that an audit would expect deny to be configured explicitly? That seems like a fairly compelling reason that deny = 3 default for compliance seems like an odd choice?

---

For what it's worth, Arch does document this issue for users, getting a change for Arch to configure pam_faillock (or disable it) AFAIK relies on you to make it clear via documentation, otherwise like you've responded, they defer us to their docs due to their own policy to respect upstream (with the intent that users on Arch get defaults from upstream, usually to avoid surprise changes when troubleshooting like other distros impose).

I have no issue adjusting configuration myself, but considering the number of users that have negative experiences (regardless of Arch specifically), I wanted to add another voice of reason to consider the feedback as something actionable by linux-pam.

---

And yes, these defaults do not make much sense for regular workstation installations but there most probably the pam_faillock does not make sense to be placed in the default PAM stack configuration at all.

It would be great if you can add that to the docs for the module 👍

Is it your opinion that pam_faillock is not worthwhile for most Desktop users security under any configuration? Is it not intended to protect a desktop user in any meaningful way if deny was adjusted to something more tolerable?

What about servers where security is usually more important, is deny = 3 acceptable? Or would you suggest not using pam_faillock there either, or bumping it up to what value?

[ChristophSchmidpeter]

There was no change in defaults for pam_faillock! That Arch Linux decided to put pam_faillock as a module that is present by default in the configuration and not change the default either by patching the code or providing a default config file with some settings that would be more reasonable for general use cases, is their fault! I am going to close this issue.

@t8m The issue here is about having sane defaults provided by upstream: Sane upstream defaults are preferable to forcing downstream to amend to sane defaults. The here given upstream defaults of a retry count of 3 within a fail interval of 15 min resulting in 10 min lockout from the system are arguably not sane defaults at all for average users. Therefore, the issue should be reopened in my opinion.