Description of problem: pam_tally2 could not meet requirement AC-7 of the NSS-1253: "The information system enforces a limit of consecutive invalid access attempts [Assignment: organization-defined number, or a maximum of 3] by a user during a [Assignment: organization-defined time period, or at least 15 minutes]. The information system automatically [Selection: locks the account/node for an [Assignment: organization-defined time period at least 10 minutes], delays next login prompt according to [Assignment: organization defined delay algorithm] when the maximum number of unsuccessful attempts is exceeded. This control also applies to remote access logon attempts. " The problem is that pam_tally2 does not keep track of the time duration that a user has consecutive failed login attempts.
Created attachment 411370 [details] pam_tally3 time-based account lockout threshold Implements pam_tally3.so module. This a feature addition to pam_tally2 which implements a time-based account lockout threshold. After a specified amount of time, the account counter will be reset.
The problem with pam_tally3 (and pam_tally2 as well) is that it contains races. Multiple simultaneous log-in attempts will cause false lockouts in case the logins would be succesfull otherwise or in other cases the count of failed attempts might be lower than the actual amount. In case of pam_tally3 that means that sometimes the fail time records might be lost. I am also not too fond of adding a separate module for this. If the races are deemed not to be serious then we might just add a separate file with the fail time records with fixed record length per user as in the current tallylog file. If we'd like to at least partially solve the problem with races then a format similar to btmp could be used. This of course brings the problem with potentially slowing the logins as the btmp file grows and creates a problem with the need to rotate the file. The rotation would be complicated because during the rotation the old events could be lost. The third option perhaps the most accurate one would be to use some kind of database (SQLite?) for storing the data. However this is really heavyweight solution.
We have pam_faillock now in RHEL-6 which solves the problem of tracking last n-attempts per user and also solves the race problem by using different PAM configuration and different storage of the data.