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. :)<br>
<br clear="all">--<br>Andrew Arnott<br>"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<br>
<br><br><div class="gmail_quote">On Wed, May 13, 2009 at 11:12 AM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com">breno@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Andrew,<br>
<br>
Please understand that it may well be impossible or at least<br>
inadvisable to have a discussion into specific scenarios where asking<br>
for a password change might be a good idea from a security viewpoint.<br>
<div class="im"><br>
<br>
On Wed, May 13, 2009 at 10:36 AM, Andrew Arnott <<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>> wrote:<br>
> Ok, so I think I see what you're saying, but rather than just a simple<br>
> password change, it sounds like this scenario warrants the OP challenging<br>
> the user.<br>
><br>
> Scenario 1:<br>
> User walks up to a kiosk and notices that a prior user didn't log out of<br>
> their OP. He maliciously leverages that to log into an RP using the victims<br>
> OP account. The RP detects strange behavior (somehow). The RP wants to<br>
> signal this to the OP.<br>
><br>
> Scenario 2:<br>
> Attacker phishes OP credentials out of a victim, or otherwise steals login<br>
> rights at the OP. Attacker logs into an RP as the victim. The RP detects<br>
> strange behavior and wants to signal this to the OP.<br>
><br>
> Either way, having the OP help the user change their password is not a<br>
> mitigation to this problem, IMO. Now, simply using the existing PAPE<br>
> extension, the RP could force the user to re-login to their OP, which would<br>
> mitigate scenario 1. But scenario 2 could only be solved by the OP sending<br>
> the user through extra identity checks, such as "where were you born?" type<br>
> questions.<br>
<br>
</div>Sarah Palin would have something to say about this, I am sure.<br>
<div><div></div><div class="h5"><br>
>If the user failed the test, then the OP would need to use<br>
> another channel to notify the genuine user that it's time to reset their<br>
> password. If the user passed the test, then the "suspicious activity" was<br>
> legitimate and no password reset is necessary.<br>
><br>
> So in no case does it seem useful for the OP to jump directly to "change<br>
> password".<br>
><br>
> --<br>
> Andrew Arnott<br>
> "I [may] not agree with what you have to say, but I'll defend to the death<br>
> your right to say it." - Voltaire<br>
><br>
><br>
> On Wed, May 13, 2009 at 9:41 AM, George Fletcher <<a href="mailto:gffletch@aol.com">gffletch@aol.com</a>> wrote:<br>
>><br>
>> The key is that as an RP, you have to be able to shut down "bad accounts"<br>
>> and if that account is an OpenID (or any other federated identity), then<br>
>> there is no way for the user (good or other wise) to reset things. They are<br>
>> locked out completely. Hence, in order to enable a good experience for<br>
>> users, the RP would like the OP to do something to prove the user is really<br>
>> "good" before the RP will let them back in. This does of course not protect<br>
>> against the attacker going through the hoops to prove the attacker is<br>
>> "good", but I'd say that's out of scope for this proposal.<br>
>><br>
>> Thanks,<br>
>> George<br>
>><br>
>> Andrew Arnott wrote:<br>
>>><br>
>>> Hi Breno,<br>
>>><br>
>>> But if the RP detects malicious activity, why would it ask the OP to have<br>
>>> the user change their password? Isn't it too late by then, and wouldn't it<br>
>>> be asking the malicious user to reset the password, thus locking out the<br>
>>> real user?<br>
>>><br>
>>> Also, some OPs don't even use passwords to authenticate their users, so<br>
>>> whatever we come up with, the extension should be able to behave reasonably<br>
>>> in that case.<br>
>>> --<br>
>>> Andrew Arnott<br>
>>> "I [may] not agree with what you have to say, but I'll defend to the<br>
>>> death your right to say it." - Voltaire<br>
>>><br>
>>><br>
>>> On Wed, May 13, 2009 at 9:03 AM, Breno de Medeiros <<a href="mailto:breno@google.com">breno@google.com</a><br>
>>> <mailto:<a href="mailto:breno@google.com">breno@google.com</a>>> wrote:<br>
>>><br>
>>> Let's give a concrete scenario:<br>
>>><br>
>>> 1. RP detects malicious activity on the user's account at the OP.<br>
>>><br>
>>> 2. In such cases, the RP would have asked the user to reset the<br>
>>> password. However, this user logs in via OpenID so the RP does not<br>
>>> have the choice.<br>
>>><br>
>>> 3. The RP puts some messaging that the user should change their<br>
>>> password at the OP. However, because there is no standard to even<br>
>>> communicate which URL at the OP the user can change password, the<br>
>>> experience is broken. A lot of users either don't know (without help<br>
>>> from the OP) how to change their passwords.<br>
>>><br>
>>> 4. Users give up, or seek personal assistance.<br>
>>><br>
>>><br>
>>> On Tue, May 12, 2009 at 8:17 PM, Santosh Rajan<br>
>>> <<a href="mailto:santrajan@gmail.com">santrajan@gmail.com</a> <mailto:<a href="mailto:santrajan@gmail.com">santrajan@gmail.com</a>>> wrote:<br>
>>> > Wouldnt it be better if the OP took complete responsibility of<br>
>>> the users<br>
>>> > security instead of bringing the RP into the loop? OP can decide<br>
>>> based on<br>
>>> > the users usage pattern how often he must change his password<br>
>>> and post a<br>
>>> > recommendation to the user whenever he logs in.<br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> --Breno<br>
>>><br>
>>> +1 (650) 214-1007 desk<br>
>>> +1 (408) 212-0135 (Grand Central)<br>
>>> MTV-41-3 : 383-A<br>
>>> PST (GMT-8) / PDT(GMT-7)<br>
>>> _______________________________________________<br>
>>> general mailing list<br>
>>> <a href="mailto:general@openid.net">general@openid.net</a> <mailto:<a href="mailto:general@openid.net">general@openid.net</a>><br>
>>> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
>>><br>
>>><br>
>>> ------------------------------------------------------------------------<br>
>>><br>
>>> _______________________________________________<br>
>>> general mailing list<br>
>>> <a href="mailto:general@openid.net">general@openid.net</a><br>
>>> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
>>><br>
><br>
><br>
<br>
<br>
<br>
</div></div>--<br>
<div><div></div><div class="h5">--Breno<br>
<br>
+1 (650) 214-1007 desk<br>
+1 (408) 212-0135 (Grand Central)<br>
MTV-41-3 : 383-A<br>
PST (GMT-8) / PDT(GMT-7)<br>
</div></div></blockquote></div><br>