Assurance

[Stefan Wahe <>]

Actually we have looked at this at Madison.  We are setting the counter to a 
threshold that reduces the entropy below a specific level.  The credential 
set is then reduced from Silver compliance until the user reset the password. 
 The user will not be able to authenticate to applications that are requiring 
silver credentials. But they can still use their credentials to authenticate 
to other local applications that do not require InC silver credentials.

So really we are not completely expiring the password.

We are currently going through an audit.  We will see if this (a) passes the 
audit and (b) is acceptable by the assurance committee.

Thanks - Stefan
   


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Stefan Wahe
University of Wisconsin - Madison
Division of Information Technology
IT Security Officer
608.265.1177



On Aug 8, 2012, at 2:53 PM, Jon Miner wrote:

> On 8/8/12 1:51 PM, Joe St Sauver wrote:
>> Benn asked:
>> 
>> #- 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)
>> 
>> My concern with employing that approach would be that it could easily be
>> exploited for a trivial denial of service attack: strobe all discernable
>> accounts with sufficient attempts to trigger expiration, then watch
>> a synchronized flood of users who can't successfully change their old
>> (now expired) passwords deluge your help desk/account clerk for manual
>> assistance. (Yes, I know that users should be able to readily change
>> their passwords, but as a practical matter, that may be an unfounded
>> expectation.)
>> 
>> Forced password changes is particularly tricky if password changes cannot
>> be accomplished "in-line." That is, in the old days when it was all just
>> shell access to time sharing hosts, an expired password could be handled
>> in-line just by dumping the user into the password changing facility
>> directly. However, once users begin authenticating via POP and IMAP 
>> clients,
>> and VPN clients, and every other application under the sun, it gets a lot
>> harder to cleanly force them to a reset facility, and of course, phishing
>> makes advising them by email difficult, and the list of complications goes
>> on...
> 
> This is largely why we have just ignored this at Madison.  Fear of the DoS, 
> difficulty in communicating the situation to the user, etc.
> 
> It's an ugly situation.
> 
> jon
> 
> -- 
> .Jonathan J. Miner------------------Division of Information Technology.
> |
>                  University Of Wisconsin - Madison|
> |608/262.9655                               Room 3148 Computer Science|
> `---------------------------------------------------------------------'
> 
> Reason #6 to quit your job and move to Key West:  Everybody stares at me 
> when
> I drink margaritas at meetings.
>    -- Christopher Shultz and David L. Sloan, "Quit your job an move to Key 
> West"
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature