[OpenID] Password age and password reset

Wed May 13 23:51:08 UTC 2009

I understand that discussing methods for compromising accounts may have
security issues itself, but on the other hand it's hard to agree on a spec
for solving a problem that you're unwilling or unable to discuss. :)

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

On Wed, May 13, 2009 at 11:12 AM, Breno de Medeiros <breno at google.com>wrote:

> Hi Andrew,
>
> Please understand that it may well be impossible or at least
> inadvisable to have a discussion into specific scenarios where asking
> for a password change might be a good idea from a security viewpoint.
>
>
> On Wed, May 13, 2009 at 10:36 AM, Andrew Arnott <andrewarnott at gmail.com>
> wrote:
> > 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.
>
> Sarah Palin would have something to say about this, I am sure.
>
> >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
> >>>
> >
> >
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090513/a46ec726/attachment.htm>