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.<br><br>Scenario 1:<br>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.<br>
<br>Scenario 2:<br>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.<br>
<br>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. <br>
<br>So in no case does it seem useful for the OP to jump directly to "change password".<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." - Voltaire<br>
<br><br><div class="gmail_quote">On Wed, May 13, 2009 at 9:41 AM, George Fletcher <span dir="ltr"><<a href="mailto:gffletch@aol.com">gffletch@aol.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;">
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.<br>
<br>
Thanks,<br>
George<br>
<br>
Andrew Arnott wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
Hi Breno,<br>
<br>
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?<br>
<br>
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.<br>
--<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." - Voltaire<br>
<br>
<br></div><div class="im">
On Wed, May 13, 2009 at 9:03 AM, Breno de Medeiros <<a href="mailto:breno@google.com" target="_blank">breno@google.com</a> <mailto:<a href="mailto:breno@google.com" target="_blank">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></div><div class="im">
<<a href="mailto:santrajan@gmail.com" target="_blank">santrajan@gmail.com</a> <mailto:<a href="mailto:santrajan@gmail.com" target="_blank">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></div>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a> <mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><div class="im"><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br>
<br></div>
------------------------------------------------------------------------<div class="im"><br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br>
</div></blockquote>
</blockquote></div><br>