The first suggestion isn't technically possible in all scenarios (how do you do 2FA in a non-interactive scenario?) The second suggestion doesn't meet the actual requirement that James' outlined (password assurance)
Sufficient is something that can only be determined after looking at requirements. What is "sufficient" for one environment is not "sufficient" for another. So how can you say that it would be sufficient? Cheers Ken -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kurt Buff Sent: Wednesday, 25 September 2013 10:39 AM To: [email protected] Subject: Re: [NTSysADM] PCI compliance and account lockout policies Passwords at least 20 characters long (essentially passphrases), and/or 2FA. No biometrics. Exponential or at least geometric increments for system response to incorrect passwords (say, 1, 2, 4, 8, 16 seconds and so on). That should be sufficient. Kurt On Tue, Sep 24, 2013 at 5:26 PM, Rupprecht, James R. <[email protected]> wrote: > Leaving PCI aside for a moment… > > > > We are a university and are looking at pulling our medical center > users into the greater campus. On the medical center side they have > implemented lockout (we do not use lockout here) and we had a long > discussion about the effectiveness of lockouts in general. > > > > At the end of the day, the purpose of lockout is to provide a > mechanism to prevent passwords from being guessed. To be more > specific, what we really want is to manage the percentage of all > possible passwords that can be guessed. If your password policy > requires and allows only a single-character, lowercase, English > character for a password you have 26 possible passwords. Allowing 25 > failures over the life of the password would mean that only a hacker > with my luck will not pwn the password. If, however, your password > policy requires complex passwords that are at least 10 characters > long, are checked against a dictionary and have a mixture of > characters/numbers/etc., 25 attempts would be trivial. That being > said, all things being equal, the fewer guesses you allow, the better > assurance you have that the password is not compromised. It will never > be perfect, of course, because there is always a chance that someone will > guess it right the first time. > > Example: Let’s say that I have a password policy that requires users > to change their password every 90 days. Users being users, they all > wait until day 90 to change. Then I create a lockout policy that locks > the account after 6 failed attempts with a 30 minute reset window. > Given those parameters, a bad guy could make 10 guesses per hour = 240 > per day = 21,600 over the life of the password. That may or may not > be acceptable in any particular environment based on use requirements > and password entropy, but on the face of it that looks like a big > number. I would also assert that most organizations would NOT CATCH > (or at least not catch for a long time) a well-crafted guessing scheme > that used these parameters, especially if it was able to get in the door. > > > > What if I wanted more assurance than the 21,600 maximum guesses would > give me? Using the same lockout parameters I could shorten the > password age or increase the entropy I required in the password. But > if I am willing to rethink the notion of lockout and the associated > parameters, I can significantly increase the assurance AND potentially > decrease the number of calls a user makes to the helpdesk. I might > also be able to catch systematic compromise attempts more readily. Here is > what I would do. > > > > I would start by defining the maximum number of guesses I was willing > to accept over the entire life of the password (which is really what I > want to control for anyways). That decision can be made based on > password composition requirements and what the password is used for. > Next, I would keep track of every bad password attempt from all > sources over the life of the password. I would also eliminate the > notion of lockout after a few failed attempts over a short windows of > time. (A guess is a guess… there is no difference between 1,000 > guesses made in one second vs. making 1,000 guesses over a few days. > The only thing guess reset windows do for us is create helpdesk > calls.) Instead I would monitor the percentage of guesses that had > been consumed for each password over the entire life of the password. > > > > So in the example above, I want to reduce the total possible number of > guesses for each password to 1,000 over the life of the password. I > pulled > 1,000 out of thin air for this example… my thinking here is that a > normal user will not make 1,000 wrong guesses in three months. That > number should also be able to handle someone fat-fingering their > password in a smart-phone and not catching if for a day. 1,000 guesses > is just 5 percent of the possible number above (much higher assurance) > and I don’t have to use aggressive lockout to implement it. In terms > of monitoring, all I do is watch the percentage of guessed passwords > consumed and guess consumption rate for each user. Outliers will > quickly stand out and could be monitored, trigger action from the > security office and/or trigger a proactive help desk call to the user. > Once the maximum number of guesses has been consumed OR the maximum > age has been exceeded (to account for shoulder surfing and other > compromise modes), the password would be treated as expired and must be > changed. > > > > As of today, this scheme is not possible using AD or most other > authentication providers so this is all theoretical. But as password > assurance becomes more critical, Microsoft and other vendors need to > look at options like this to replace traditional, older methods in > places where high-assurance, single-factor password authentication is > required. > > James Rupprecht > > Enterprise IT Architect, Microsoft Technologies > > University of Kansas Information Technology
