Assurance

[Brendan Bellina <>]

We've recently developed logic in our LDAP authentication plug-in to keep a 
failed password counter per-account. The response to failed attempts is 
increasingly delayed as the number of attempts increases so that a brute 
force attack through Shib or directly against LDAP shouldn't prove effective. 
 The frequency of increases and increase amounts are customizable. The 
advantage of this approach over the use of the lockout features provided by 
SJES and 389 is that it defeats a brute force attack without locking out the 
valid user of the account.  We developed this in response to concerns about 
SSO being used with sensitive applications, and did not consider the 
requirements of Bronze/Silver. The plug-in is compatible with SJES 6+ and 
389. If there is anyone with interest just let me know and we can make 
consider arrangements.

Regards,

Brendan Bellina
IdM Mgr, USC

On Aug 8, 2012, at 11:00 AM, Benn Oshrin 
<>
 wrote:

> Back in December, there were some spreadsheets sent around discussing the 
> "sliders" to select password policies as required by §4.2.3.[2,3]. Bronze 
> and Silver basically reference 800-63-1 appendix A which, as I understand 
> it, essentially says your password management policy is calculated from
> 
> - The complexity required for the password (length, dictionary, composition)
> - The number of unsuccessful attempts required before the password must be 
> locked/changed
> - Time introduced to frustrate attacks, via lockouts
> 
> I'm curious about what approaches people are settling upon now. For example,
> 
> - Is anyone (considering) maintaining a simple failed authentication 
> counter per-password, and expiring the password once the counter reaches 
> the limit permitted by the complexity for the level (Bronze/Silver) of 
> interest? (ie: no lockout, no scheduled expiration)
> 
> - Where password lockout is being used (for n amount of time after m failed 
> attempts, but then unlocking the password without reset unless it has 
> expired), what "slider" settings are you using/planning to use compared to 
> what you previously used/currently use? How, if at all, are you (planning 
> on) handling DOS risk?
> 
> - Are you (planning on) requiring longer passwords?
> 
> (We discussed 2FA/OTP as a "beyond Silver" option back in March, so I'm 
> less interested in that aspect.)
> 
> Is there any sense that these requirements are "too strong" for 
> Bronze/LOA1? Or, less likely, "too weak"?
> 
> Thanks,
> 
> -Benn-