Skip to Content.
Sympa Menu

assurance - Re: [Assurance] Password reset process: Flogging the dead horse

Subject: Assurance

List archive

Re: [Assurance] Password reset process: Flogging the dead horse


Chronological Thread 
  • From: David Langenberg <>
  • To:
  • Subject: Re: [Assurance] Password reset process: Flogging the dead horse
  • Date: Wed, 7 Aug 2013 16:37:06 -0600




On Wed, Aug 7, 2013 at 3:46 PM, Eric Goodman <> wrote:

Hi all,

 

I recently met with a group that is looking to use the InCommon IAPs as guidance – or at least a comparison point – for defining appropriate verification processes for callers who have forgotten their passwords. They were particularly looking to understand what is minimally required of the password reset processes under the InCommon IAP(s) *without invalidating any existing LoA assertions*.

 

I know this is a topic that has been discussed in great detail in the past, but I just want to make sure I’m not missing anything obvious in the new InCommon IAP. In IAP 1.2, the requirements for credential renewal or re-issuance identify the following as a valid method for credential re-issuance:

 

“4.2.4.3.2 (S)(B) By use of a single-use secret delivered to the Subject from the IdPO by means of a pre-registered out of band delivery mechanism.”

 

The language here doesn’t define “out of band”, but it seems clear that sending to a preregistered email address is intended to meet this requirement.

 

So it would be sufficient to stand up a page that takes an account name as input and on submission delivers a one-time code the email address on record (assuming there is one). Ability to provide the delivered code is by itself sufficient authentication of the individual to allow changing the account password; no other authentication challenge is required to be in compliance, and a reset done following this process does not invalidate any existing LoA IAQ – Bronze or Silver – on the account.

 

### QUESTION #1: Ignoring whether you or your campus thinks this is a sufficient process, is there any disagreement that the above process would be in compliance with InCommon’s requirements for both Bronze and Silver?


The above process is exactly what UChicago has submitted to our auditors for InCommon Silver.  Though we offer delivery of the secret over SMS in addition to email.

 

 

 

Moving beyond that, if the individual is NOT able to provide to access this one time code (say the registered email address is no longer active) and none of the other two identified methods in the IAQ is available, then

 

(a) if the existing IAQ for the account is Silver, then to maintain that IAQ the individual must be re-verified as if a new user, per section 4.2.2; any other method of reissuing the user’s password (say, sending the secret to an email address gathered over the phone that was NOT previously on record for the individual) and the individual would lose the Silver IAQ eligibility.


That's exactly how our process works.  If the user is unable/unwilling to retrieve the secret, they have the option to hit a button in the application which will completely re-set them to a pre-silver state.  They have to acknowledge several warnings about this to discourage them from being immediately lazy.  After hitting the button they start over fresh with having to register addresses of record and have their identity re-proofed.
 

 

(b) if the existing IAQ for the account is Bronze, then it’s not clear what should happen, as there are no requirements under 4.2.2 for initial identify establishment for Bronze, so it’s not clear what would be required to maintain the existing Bronze IAQ; would it be IdPO’s discretion, then? (I’m certain someone raised this question on the list before, but I’m not finding that discussion in my search of the archives).

 

### QUESTION #2: Again, is this an accurate description of what is required if the re-issuance requirements cannot be met?


Can't help you much with Bronze as we're skipping Bronze for now.

Dave

--
David Langenberg
Identity & Access Management
The University of Chicago



Archive powered by MHonArc 2.6.16.

Top of Page