Allow configuring of invalid password cooldown?

[anymuster2]

I'm submitting a…

[ ] Bug
[X] Feature Request
[ ] Other (Please describe in detail)

Current Behavior

Currently, there is a hardcoded cooldown for invalid credentials of 3000ms, applied by i3lock (https://github.com/i3/i3lock/blob/main/i3lock.c#L321). Time-limited physical access to my host is not a realistic threat I face - either a hacker has no physical access, or they have it for an extended duration, not much in between.

My password is long and complex, I regularly make typos. As there is no ability to configure cool-down periods of an incorrect password but I can imagine scenarios where a user may want extended cooldown prior to the ability to reenter their password.
Instead of waiting 3+ seconds each typo, I'm currently thinking about reducing my password complexity but would prefer an option to reduce cooldown as other system aspects may be impacted by reduced complexity (ssh when password auth is enabled, for example).

Expected Behavior

Ability to configure cooldown.

Reproduction Instructions

Environment

Output of i3lock --version:

i3lock version: 

[stapelberg]

What you’re linking to is only the indicator, not an actual cooldown. AFAIR, the cooldown comes from PAM and needs to be configured there, not in i3lock.

[anymuster2]

You're half right - I've configured PAM (https://unix.stackexchange.com/questions/40954/how-does-one-change-the-delay-that-occurs-after-entering-an-incorrect-password , I seemed to need both the nodelay and delay= parameters for it to work).

Instant cool-down works in GDM, su, passwd etc, but the indicator blocks submission of a new attempt until it's finished sleeping - If I type an incorrect value, then mash my keyboard and hit enter while 'Verifying' is shown, it seems to wait the sleep duration, visually indicates keypresses have been input, then attempts the new password.

[stapelberg]

Yes, AFAIR, this behavior was introduced to prevent an easy denial of service attack: mashing the enter key to fill the password buffer with invalid attempts, that i3lock would then dutyfully process one after the other, making it impossible for the owner of the laptop to log in until the time passed.

[anymuster2]

Any chance it could be configured to align with PAM cooldown or allow a duration be passed to it? If it's slower than PAM, on most hosts it would be possible to brute force via a TTY. Another use case may be a user who wants to increase time, which I assume is also not currently possible.

If Denial of Service via the attack path is a concern, then allow a cache of n-attempts and throw away any further input - based on manual testing, I think that's what may be occurring now (the cooldown doesn't block input, but only one further attempt seems to be allowed).

[stapelberg]

No, I don’t think it’s worth making this configurable (see also https://faq.i3wm.org/question/778/why-is-patch-not-merged-and-made-optional for some considerations regarding offering options).

I recommend you change this value locally and build from source.