[OpenID] Password age and password reset

[Breno de Medeiros]

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.

-- 
--Breno (Google)