[OpenID] Password age and password reset
Breno de Medeiros
breno at google.com
Thu May 14 00:03:49 UTC 2009
I understand that, and that is why I am hoping that others who
recognize the value of this technique will speak on its behalf. It
would be interesting if people with knowledge of their companies
security practices regarding account recovery could comment here (in
broad terms).
On Wed, May 13, 2009 at 4:51 PM, Andrew Arnott <andrewarnott at gmail.com> wrote:
> 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)
>
>
--
--Breno
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
More information about the general
mailing list