Assurance

[David Walker <>]

I don't think it's all that important to limit the number of failed attempts per month, only over the entire lifetime of the password.  The monthly limit is only a suggested approach.

Assuming a reasonably strong password and modest rate limiting, I would think it would be possible to know, say, a few weeks before the lifetime limit is reached, giving ample time to address the issue without a lockout.

David

On Tue, 2013-06-25 at 21:35 +0000, Capehart,Jeffrey D wrote:
>     The relevant portion of SP 800-63 can be found on pages 73-74 in section 8.2.3 "Throttling Mechanisms" where counting failed logins is mentioned.
>     
>     One technical consideration for hyperactive email checkers with the wrong password is that you only need to count the failed authentication once as long as the source IP address and password supplied are the same.  Subsequent failed attempts with the same account/password do not increase the probability of success.
>     
>     The wording of the requirement is "The Verifier shall implement a throttling mechanism that effectively limits the number of failed authentication attempts an Attacker can make on the Subscriber's account..."
>     
>     One throttling mechanism could be to block the attacker's IP address from authenticating after N failed authentication attempts regardless of whether the target was a specific user account or any user account.
>     
>     The exponential delay also would qualify as a throttling mechanism.
>     
>     Note that the InCommon Silver v1.2 spec doesn't explicitly require a counter; limiting the invalid attempts is the goal, to meet the low probability of success over the credential lifetime.
>     
>     The 4.2.3.3 requirement says "The Authentication Secret and the controls used to limit online guessing attacks shall ensure that an attack targeted against a given Subject's Authentication Secret shall have a probability of success of less than 2^-14 (1 chance in 16,384) over the life of the Authentication Secret.  This requires that an Authentication Secret be of sufficient complexity and that the number of invalid attempts to enter an Authentication Secret for a Subject be limited."
>     
>     The IAAF suggests that "To the extent possible, the IdPO's system architecture may need to be resistant to denial of service attacks."
>     
>     For Windows Active Directory, here's some TechNet guidance from Microsoft:
>     
>     Security Monitoring and Attack Detection
>     http://technet.microsoft.com/en-us/library/cc875806.aspx
>     
>     Jeff
>     
>     Jeff Capehart, CISA
>     IT Audit Manager
>     University of Florida - Office of Internal Audit
>     (352) 273-1882
>     
>     http://oia.ufl.edu
>     
>     
>     -----Original Message-----
>     From:  [] On Behalf Of Brendan Bellina
>     Sent: Tuesday, June 25, 2013 3:10 PM
>     To: <>
>     Subject: Re: [Assurance] Counting Failed Logins Update
>     
>     Joe,
>     
>     I think these DOS points are well-taken and have raised them myself with auditors and such who don't seem to take this risk seriously.  Since University account logins are usually obvious and systems are public we are at greater risk than corporations where account logins are not obvious and systems are not public.
>     
>     One way to thwart brute force attacks without adversely affecting account owners is to exponentially slow down the responses to bad password attempts, rather than all password attempts. There is no need to lock out the account in this case.  This also prevents the accidental lockouts that would be caused by the "hyperactive email checkers" you refer to.
>     
>     Regards,
>     
>     Brendan Bellina
>     USC ITS IdM Mgr