I got rid of the useless lock screen password delay when I mistype my password (set graceLockTimer interval to zero in usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/LockScreenUi.qml) but lately I still am experiencing a delay. It looks like about a two second delay while it “considers” whether my password is wrong before it “shakes it’s head no”. When I type the correct password, my screen unlocks instantly.
How can I get rid of this useless delay?
It’s not actually “useless”, it’s a security feature. By forcing a delay between an incorrect password attempt and the next attempt, it makes brute-force attacks harder.
I’ve been working in computer security for 38 years. Short answer: it’s useless.
Longer answer: there’s no imaginable GUI-based brute force attack that will discover my password, other than a quadrillion to one lucky chance, and adding a few seconds delay does absolutely nothing to change those odds for any real world foreseeable attack.
If I mistype my password, there is literally no reason to wait. And if there was an actual real world risk that someone would launch a GUI-based attack on my lockscreen (let’s say a usb key that spews passwords out rapidly), then developers would have a delay that kicks in after a dozen or more mistyped passwords; or better yet; just put in a really big delay after, I don’t know, maybe a hundred or a thousand attempts.
If on the other hand, you have a terrible password, and it might be easily guessable to someone, then the two second delay also does really basically nothing, because “easily guessable” generally means twenty or less or maybe even a 100 or less passwords, and if someone has access a laptop with a password where the password is terrible, you’ve made them have to wait golly like three minutes.
But the most likely scenario for guessing your lockscreen password is that they found your password written down somewhere in which case the delay does even less good than nothing.
The ONLY thing the delay accomplishes is to annoy me when I make a typo. That is it. There is literally NO OTHER EFFECT.
These delays are in place solely for traditional reasons. The were first put into place on terminal-based and network-based login prompts, where the speed of brute force attacks was limited only by the network speed (which was slower then). And that was also an era when even experienced people really did use legitimately terrible passwords quite often.
Of course, in theory, in network situations even today these delays MIGHT still make sense. But, as I suggested above, what real world systems that actually see real attacks do is NOT a delay. Like ssh typically has no bad password delay. Rather, it’s assumed that you’ll have fail2ban or similar just block things entirely after X number of bad attempts, rather than needlessly adding a delay that will not affect an automated program at all, but will annoy real human beings making typos.
It is just tradition and momentum that gets people to stick with these delays that do nothing, when there’s smarter solutions that actually work.
This is likely to be overwritten without warning.
That was the first thing I checked. My value of zero is still in place, but there is still a delay, presumably coming from some other setting somewhere? Or something someone decided to hard-code into a recent change? Under the misguided notion that delays always equal more security.
You mentioned this already, please don’t go on about it. If you’re unhappy with it I suggest submitting a change request to the maintainers of the affected packages, which I presume are upstream of archlinux even.
I’m not familiar with exactly how the Plasma lock screen authentication is handled but the PAM also has a delay by default that may affect the GUI authentication. From memory you’d need to add a nodelay flag to entries in /etc/pam.d/system-auth
This may be of interest - it is old (2019)
It shouldn’t be an issue with today’s sddm - but nonetheless
There is several components in play - so it may be difficult to find exactly where it is implemented.
The nodelay argument as suggested by @bananamangodog is the most promising idea I have seen 
As far as I know SDDM and KDE lock screen are 2 entirely different things. I did initially consider SDDM or Plasma Login Manager, but from what I understand of them they only handle the initial login, not the lock screen after already logging in.
Nonetheless they may share some component of user authentication so I guess it depends what level the delay is configured at.
They are, yes.
The Plasma login screen is handled by the display manager — traditionally, this has been sddm since Plasma 5, although for Plasma 6 there is now also plasma-login-manager, which is still fairly new and, unlike sddm, is completely developed by KDE themselves.
The lock screen in Plasma is handled by kscreenlocker.
To get my Yubikey working for login and unlocking the lock screen in Plasma Login Manager, I had to modify these two files:
/etc/pam.d/login:auth sufficient pam_u2f.so cue
/etc/pam.d/system-login:auth sufficient pam_u2f.so cue
But I don’t remember which one was for the lock screen. Maybe nodelay can still help here.
However, I found the post from linux-aarhus pretty informative!
I thought this delay OP is talking about was for those instances where someone is sort of glancing at your hands while you type your pass and later want to try getting access by guessing what it was.
Would be sort of useful if an alert box was shown when the real person logged in, that “There has been X attempts to log in with your username while using the following passwords:”
And then a list of what was used.
You generally don’t store passwords in a reversible form if you care about security. Modern authentication systems store hashed (and salted) versions of passwords.
(So this would circumvent all that.)
The other side of the coin is that these aren’t actual passwords, but incorrect entries. If any of them even remotely resemble my actual password, it’s time to change it.
The display of incorrect entries is also uncritical because they’re only shown after a successful login.
Yeah but it doesn’t matter. The problem with this idea is that the operating system will be storing wrong passwords INCLUDING YOUR SLIGHTLY MISTYPED ONES somewhere within the system. The exploitation of such a feature greatly outweighs its benefit.
A smarter idea along these same lines would be to snap a photo each time someone typed your password incorrectly, and save that and show it to you. There are still some potential problematic issues there. But not nearly so serious as the first idea. This may well be implemented somewhere.
Another somewhat similar thing, which I actually do for all REMOTE logins, is that any remote login that does not come from a known system results in me receiving a text message that I logged in from an unexpected location.
(Auditing for intrusions is in many ways more powerful than blindly trying to prevent intrusions.)
You can restrict remote logins to only known systems via sshd_config. Login attempts from anywhere else will then silently be dropped.
I don’t see what the difference is between saving photos and text. Although the latter can certainly be encrypted as well.
@Aragorn
The question is, would you rather know that someone can successfully log into your account, or would you want to blindly prevent them from doing it in one known situation?
In terms of security, that’s not a black and white issue. It’s a policy issue with different answers in different contexts.
@pwx
Photos of anyone including myself trying to use my computer is not a threat to the security of my computer. Having my photo, or other people’s photos won’t let anyone log in. There may still be legitimate privacy issues, but that’s a different thing.
Storing my mistyped passwords in any way that could conceivably somehow be retrieved by someone else (e.g. it’s a multi user system; or e.g. it saves this somewhere that is backed up to a more vulnerable location) could become a massive security threat, as my hard to guess password suddenly becomes almost trivial to guess.
I have tried this and didn’t meet with success. I added nodelay to the auth line for unix.so in system-auth. The man page for unix.so does say it has a default delay of two seconds which is what I’m experiencing. But nodelay didn’t fix this. I didn’t restart anything or reboot, but PAM changes are normally live immediately.
The documentation for kscreenlocker says it uses the kde PAM service. Which for some reason was undefined on my laptop. There was a pacnew and a pacsave for kde but no regular kde PAM service file. Creating one (from the pacsave file) didn’t help either. Of course, the kde file just includes (ultimately) the system-auth file.
Mod edit: Consecutive posts merged.
I’m just guessing at this point but if both options aren’t removing the delay, perhaps try editing /usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/LockScreenUi.qml and disabling the animation?
You’ll likely need both options to remove the delay as well.
You’re moving the goalposts. I was only talking of hardening your system.
Of course it would be a problem if anyone other than yourself can log into your account. That goes without saying.