[OpenID] Password age and password reset

Wed May 13 02:20:42 UTC 2009

In most nac regimes, such those requiring periodic health recertification (and rekeying of the peap-tls authenticator, or getting a new tokencode from such as a connected peap-rsa token device), it is the rp role that defines the period.

In rsa peap, the rp is not entitled to know anything about the users pin. An idp can interact, for pin distrijution, pin refresh, rekey peap session keys etc..

Don't see why openid cannot be another nac enforcement scheme (alongside ipsec healh certs, saml assertions)

-----Original Message-----
From: Allen Tom <atom at yahoo-inc.com>
Sent: Tuesday, May 12, 2009 7:53 PM
To: Breno de Medeiros <breno at google.com>; OpenID List <general at openid.net>
Subject: Re: [OpenID] Password age and password reset

Hi Breno,

Are there any risks with exposing the password age to RPs, especially if
there is not a strong trust relationship between the RP and OP? As far
as I know, the password age is not a typical attribute that is shared
via other SSO protocols.

It does make sense for an RP to be able tell the OP that it only wants
an assertion if the user's password was validated within a certain time.
(Similar to SAML's AuthnInstant). It obviously doesn't make sense for
the OP to share information about the password strength, so I'm
wondering if the PW age would fit into the same category.

Also, because Account Recovery and Login are pretty much equivalent,
Account Recovery Proofing age (secret questions, alternate email
addresses, etc) should probably be bucketed with PW age. For instance,
if the attacker has access to the Account Recovery data, then it doesn't
matter if the user changes their password, since the attacker will just
recover the account after the user changes the password.

I do think it's odd than an RP can force a password change. It sounds
like you're looking for a mechanism for an RP to report "suspicious
activity" on an account. Perhaps the best solution would be for the RP
to just inform the user of suspicious activity, and to recommend that
the user change their PW.

Allen

Breno de Medeiros wrote:
> I have created a wiki page on ideas for RPs to request password age
> and reset of passwords at the OP.
>
> http://wiki.openid.net/Sending-Password-Age-Information
>
> (cut and pasted here for convenience)
>
> I would like to get a quick sense from this community if this is the
> right direction, and if so, to move on quickly towards forming a WG to
> discuss technical details on how this could be implemented.
>
> This is motivated by direct feedback that this is a pressing need,
> possibly gating major RP deployments.
>
> -----
>
>
>
> One consideration in replacing traditional password login with OpenID
> is how to deal with abuse and spam. In particular, the time since the
> user changed a password is considered a useful signal. Even more
> importantly, the ability to require users to change passwords if often
> a critical step in recovering a compromised account to a safe state.
>
>
>
> Objective
>
>
>
> This page provides ideas on how RPs request from OP the time of last
> password change, and how they may request a password change. First I
> describe possible password age request/password change request flows.
>
>
>
> Initial assessment
>
>
>
>    1. User arrives at RP, starts the OpenID login flow. RP optionally
> attaches to the authorization request an extension to indicate that
> the time of last password change is requested. RPs could choose to do
> this on every login or following some heuristic.
>    2. User is directed to OP where she authenticates (via cookie,
> password, ...) and approves the request (maybe transparently in a
> checkid_immediate request).
>    3. The User returns to the RP with a positive assertion that
> potentially includes signed password age data.
>
>
>
> At this point, the RP may decide to request that the OP prompt the
> user for a password change because the account the user tried to log
> in is under suspicion from fraud/abuse. If so, one of the following
> flows could take place.
>
>
>
> Flow #1 (Use of password change URL)
>
>
>
>    1. RP gives some warning to user, explaining that for her
> protection she should change her password at the OP. The RP provides a
> link to the password change URL at the OP. The RP instructs the user
> to change the password at the OP and return to the RP site to login
> again.
>    2. The user clicks on the link or otherwise navigates to the OP
> password change URL and changes her password.
>    3. User navigates to RP and tries to login again.
>    4. RP repeats steps 1--3 above, obtains a fresher password date,
> validating that the user has changed her password, and uses that
> information to decide if to allow the user back into the account.
>
>
>
> Note: In this flow, the OP provides an additional password change URL
> in every response to the password age query. For reasons of
> optimization, the RP may want to include such password age query
> extension frequently (or always) in sign-in requests.
>
>
>
> Flow #2 (Use of password reset flow)
>
>
>
>    1. RP directs user to OP with an extension to indicate that a
> password change is requested.
>    2. OP presents the user with the option to change the password.
>    3. User approves and is directed to RP with signed password age information.
>    4. RP uses the password age information to detect that the user's
> password at the OP has changed, and uses that information to decide if
> to allow the user back into the account.
>
>
>
> Note: In this flow, the OP will have to provide support for password
> change as a part of an OpenID authentication flow.
>
>
>
> Implementation considerations
>
>
>
> Such flows can be implemented using either AX or probably more
> logically, PAPE. The specific mechanisms can be discussed in a WG.
>
>
>
> Usability considerations
>
>
>
> Both flows will require that RPs provide good context for the user for
> the steps to follow, when leading to the password change. The OP may
> not possess the information that lead the RP to request a password
> change and therefore is likely to use generic language and allow user
> discretion on whether or not to choose the password.
>
>

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general