Assurance

[David Walker <>]

I also like this proposal.  It occurs to me that counting failed attempts could also be used as a replacement for password expiration based on age.  Just count the total number of failed attempts against a password and flag it to be changed, say, a month or two before the maximum number of failures could be reached.

This way, users are not forced to do password changes unless they're being attacked.

David

On Mon, 2013-06-03 at 16:16 +0000, Rank, Mark wrote:
>     Benn:
>     
>     I would agree with Eric. I feel you have a solid proposal to move forward with. 
>     
>     My only comment builds on Eric's comments addressing the single point of failure issue. If I am understanding the proposal fully, you are dependent on the logging from each credential store. It is probably implicit in your proposal (and likely addressed by other parts of the IAP) but you may want to call out explicitly that integrity checking of logging is critical. Any gaps in logging through faults at the credential store or during a fault of counter might invalidate all IAQ's unless the validators are taken off line for holders of IAQ's. 
>     
>     Let me know if you want to discuss further.
>     
>     Regards,
>     Mark
>     
>     --------------------------------------------------
>     Mark Rank
>     Project Manager - Identity & Access Mgt
>     UCSF Information Technology Services (ITS)
>     email: 
>     phn:414-331-1476
>     --------------------------------------------------
>     
>     ________________________________________
>     From:  [] on behalf of Eric Goodman []
>     Sent: Friday, May 31, 2013 3:49 PM
>     To: 
>     Subject: RE: [Assurance] Failed Authentication Counter Strawman
>     
>     I like your proposal.
>     
>     I hadn't realized 800-63-1 changed the requirements and their arguments against simple counters are interesting. I think you address the first and the last very well, I had some additional thoughts on the second one:
>     
>     "The approach is a single point of failure."
>     
>     In addition to the points you make countering this statement:
>     
>     * If the failure is a failure to send current statistics to the central "counter", as long as the problem doesn't persist for more than 72 hours and you can resync the counts before the 72 hour timeframe is up, you wouldn't need to stop asserting the IAQ.
>     
>     * You can still implement rate-limiters at the individual authenticators (i.e., limited login attempts/unit time). At the end of any such outage, if stats from the outage period were unavailable, you could simply increment all of your users' counters by the maximum possible attempt rate * duration of the outage.
>     
>     I can envision other attacks that would allow someone to bypass a central counter (e.g., compromising the count database, modifying the authenticator logs before they are written out), but those kinds of attacks are probably so intrusive that brute force limit being exceeded is the least of your worries.
>     
>     --- Eric
>     
>     -----Original Message-----
>     From:  [] On Behalf Of Benn Oshrin
>     Sent: Friday, May 31, 2013 2:52 PM
>     To: 
>     Subject: [Assurance] Failed Authentication Counter Strawman
>     
>     As mentioned on a couple of previous calls, I've been interested in a solution for counting failed authentication attempts. I've drafted a strawman, available for review at
>     
>       https://spaces.internet2.edu/x/kAtOAg
>     
>     I'd be interested in comments and feedback, and assuming no fatal flaw, I'd also be interested if anyone else is considering a similar approach.
>     
>     Thanks,
>     
>     -Benn-