[OpenID] Password age and password reset

[Andrew Arnott]

Ok, so I think I see what you're saying, but rather than just a simple
password change, it sounds like this scenario warrants the OP challenging
the user.

Scenario 1:
User walks up to a kiosk and notices that a prior user didn't log out of
their OP.  He maliciously leverages that to log into an RP using the victims
OP account.  The RP detects strange behavior (somehow).  The RP wants to
signal this to the OP.

Scenario 2:
Attacker phishes OP credentials out of a victim, or otherwise steals login
rights at the OP.  Attacker logs into an RP as the victim.  The RP detects
strange behavior and wants to signal this to the OP.

Either way, having the OP help the user change their password is not a
mitigation to this problem, IMO.  Now, simply using the existing PAPE
extension, the RP could force the user to re-login to their OP, which would
mitigate scenario 1.  But scenario 2 could only be solved by the OP sending
the user through extra identity checks, such as "where were you born?" type
questions.  If the user failed the test, then the OP would need to use
another channel to notify the genuine user that it's time to reset their
password.  If the user passed the test, then the "suspicious activity" was
legitimate and no password reset is necessary.

So in no case does it seem useful for the OP to jump directly to "change
password".

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - Voltaire


On Wed, May 13, 2009 at 9:41 AM, George Fletcher <gffletch at aol.com> wrote:

> The key is that as an RP, you have to be able to shut down "bad accounts"
> and if that account is an OpenID (or any other federated identity), then
> there is no way for the user (good or other wise) to reset things. They are
> locked out completely. Hence, in order to enable a good experience for
> users, the RP would like the OP to do something to prove the user is really
> "good" before the RP will let them back in. This does of course not protect
> against the attacker going through the hoops to prove the attacker is
> "good", but I'd say that's out of scope for this proposal.
>
> Thanks,
> George
>
> Andrew Arnott wrote:
>
>> Hi Breno,
>>
>> But if the RP detects malicious activity, why would it ask the OP to have
>> the user change their password?  Isn't it too late by then, and wouldn't it
>> be asking the malicious user to reset the password, thus locking out the
>> real user?
>>
>> Also, some OPs don't even use passwords to authenticate their users, so
>> whatever we come up with, the extension should be able to behave reasonably
>> in that case.
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the death
>> your right to say it." - Voltaire
>>
>>
>> On Wed, May 13, 2009 at 9:03 AM, Breno de Medeiros <breno at google.com<mailto:
>> breno at google.com>> wrote:
>>
>>    Let's give a concrete scenario:
>>
>>    1. RP detects malicious activity on the user's account at the OP.
>>
>>    2. In such cases, the RP would have asked the user to reset the
>>    password. However, this user logs in via OpenID so the RP does not
>>    have the choice.
>>
>>    3. The RP puts some messaging that the user should change their
>>    password at the OP. However, because there is no standard to even
>>    communicate which URL at the OP the user can change password, the
>>    experience is broken. A lot of users either don't know (without help
>>    from the OP) how to change their passwords.
>>
>>    4. Users give up, or seek personal assistance.
>>
>>
>>    On Tue, May 12, 2009 at 8:17 PM, Santosh Rajan
>>    <santrajan at gmail.com <mailto:santrajan at gmail.com>> wrote:
>>    > Wouldnt it be better if the OP took complete responsibility of
>>    the users
>>    > security instead of bringing the RP into the loop? OP can decide
>>    based on
>>    > the users usage pattern how often he must change his password
>>    and post a
>>    > recommendation to the user whenever he logs in.
>>
>>
>>
>>    --
>>    --Breno
>>
>>    +1 (650) 214-1007 desk
>>    +1 (408) 212-0135 (Grand Central)
>>    MTV-41-3 : 383-A
>>    PST (GMT-8) / PDT(GMT-7)
>>    _______________________________________________
>>    general mailing list
>>    general at openid.net <mailto:general at openid.net>
>>    http://openid.net/mailman/listinfo/general
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090513/8a146302/attachment.htm>