pam_unix: Fix delay UX #778
Comments
|
I was annoyed by the delay and was thinking opening a PR today itself, when I came across this issue. I support your idea more or less, but I think, we can keep a count of number of times the password has been incorrectly entered consecutively. If its less than three, then a 0.1 second delay is enough. Otherwise, (0.5*count) second delay. Doesn't that sound better? |
|
Yes, that is clearly the best way to do it, and it's how most password systems work. I think Windows has done it since at least XP. However because PAM has a weird architecture (it's a library in the client rather than a single persistent system component) it's quite difficult to store persistent information. The So you would either need to make a new plugin with a similar complexity to Doable but quite a lot of work, whereas changing the default is a one line change. It also wouldn't require distros to change their configs so we might actually get a (suboptimal) fix before I die! Glad someone else agrees anyway! I'm going to make a PR. If you want to make a PR for a new exponential delay plugin go ahead. I did start writing one but I hate C so... |
The default fail delay is 2 seconds (+/- 50% randomly). This is done to prevent brute force attacks, but unfortunately because isn't applied exponentially, it also greatly degrades the UX for legitimate users. Every typo is immediately met with an annoying 2 second delay. A full fix would be to persist the login failure times and apply an exponential delay (this is what Windows does), however this is quite complicated due to PAM's architecture (see the `faillock` plugin for an example of this). This simple fix greatly improves the UX at very minimal security cost. Any brute force attack that can tolerate a 0.5 second delay will also work with a 2 second delay. In other words a factor of 4 is nothing from an attacker's perspective, but makes a big difference from a legitimate user's perspective. Fixes linux-pam#778
The default fail delay is 2 seconds (+/- 50% randomly). This is done to prevent brute force attacks, but unfortunately because isn't applied exponentially, it also greatly degrades the UX for legitimate users. Every typo is immediately met with an annoying 2 second delay. A full fix would be to persist the login failure times and apply an exponential delay (this is what Windows does), however this is quite complicated due to PAM's architecture (see the `faillock` plugin for an example of this). This simple fix greatly improves the UX at very minimal security cost. Any brute force attack that can tolerate a 0.5 second delay will also work with a 2 second delay. In other words a factor of 4 is nothing from an attacker's perspective, but makes a big difference from a legitimate user's perspective. Fixes linux-pam#778
The default fail delay is 2 seconds (+/- 50% randomly). This is done to prevent brute force attacks, but unfortunately because isn't applied exponentially, it also greatly degrades the UX for legitimate users. Every typo is immediately met with an annoying 2 second delay. A full fix would be to persist the login failure times and apply an exponential delay (this is what Windows does), however this is quite complicated due to PAM's architecture (see the `faillock` plugin for an example of this). This simple fix greatly improves the UX at very minimal security cost. Any brute force attack that can tolerate a 0.5 second delay will also work with a 2 second delay. In other words a factor of 4 is nothing from an attacker's perspective, but makes a big difference from a legitimate user's perspective. Fixes linux-pam#778
The default fail delay is 2 seconds (+/- 50% randomly). This is done to prevent brute force attacks, but unfortunately because isn't applied exponentially, it also greatly degrades the UX for legitimate users. Every typo is immediately met with an annoying 2 second delay. A full fix would be to persist the login failure times and apply an exponential delay (this is what Windows does), however this is quite complicated due to PAM's architecture (see the `faillock` plugin for an example of this). This simple fix greatly improves the UX at very minimal security cost. Any brute force attack that can tolerate a 0.5 second delay will also work with a 2 second delay. In other words a factor of 4 is nothing from an attacker's perspective, but makes a big difference from a legitimate user's perspective. Fixes linux-pam#778
The default fail delay is 2 seconds (+/- 50% randomly). This is done to prevent brute force attacks, but unfortunately because isn't applied exponentially, it also greatly degrades the UX for legitimate users. Every typo is immediately met with an annoying 2 second delay. A full fix would be to persist the login failure times and apply an exponential delay (this is what Windows does), however this is quite complicated due to PAM's architecture (see the `faillock` plugin for an example of this). This simple fix greatly improves the UX at very minimal security cost. Any brute force attack that can tolerate a 0.5 second delay will also work with a 2 second delay. In other words a factor of 4 is nothing from an attacker's perspective, but makes a big difference from a legitimate user's perspective. Fixes linux-pam#778
The default fail delay is 2 seconds (+/- 50% randomly). This is done to prevent brute force attacks, but unfortunately because isn't applied exponentially, it also greatly degrades the UX for legitimate users. Every typo is immediately met with an annoying 2 second delay. A full fix would be to persist the login failure times and apply an exponential delay (this is what Windows does), however this is quite complicated due to PAM's architecture (see the `faillock` plugin for an example of this). This simple fix greatly improves the UX at very minimal security cost. Any brute force attack that can tolerate a 0.5 second delay will also work with a 2 second delay. In other words a factor of 4 is nothing from an attacker's perspective, but makes a big difference from a legitimate user's perspective. Fixes linux-pam#778
|
I agree that lowering the default delay would be a considerable UX improvement. While something more elaborate may be even better, I feel that having the simple fix now would be great regardless (it doesn't preclude further improvements in the future). IIRC, I used to lower the delay with a line like |
PAM's
pam_unixhas a default fixed delay of approximately 2 seconds. As far as I can tell most software and distros stick with this and use it for everything - ssh, sudo, login, etc.From a usability point of view that sucks. It's a significant amount of time to wait when you make a typo and it add dubious security benefits. There are no security benefits at all for sudo (you can just use
unix_chkpwd), and I'm dubious aboutsshd- I expect you can get around it just by creating a load of parallel connections (though I haven't tried it).I would like to fix this annoying paper cut. I can think of the following solutions and wanted your feedback on what you would accept:
faildelayto have increasing delays, and store the current delay count as part of the session (if that is possible; I couldn't quite figure it out and it seems like a bad idea to use global variables). This isn't much work either.faildelayto have increasing delays, and persist the fail information to disk in the same way thatfaillockdoes. This is a ton of work. I'll probably give up if this is the only acceptable solution.faillockto have increasing delays.sudo. It's not ideal to have the default delay as 0 because that isn't fail-safe. Every config exceptsudothen has to remember to set the delay.My preference is 1. What do you think?
The text was updated successfully, but these errors were encountered: