(light finally goes on)<br><br>Oh! Are we talking about an OP password reset where the <i>interacting user doesn't decide or know what the new password is?</i> In that case, it's a sort of force log-out. And I take it then that after that, the user must begin the account recovery stage with the OP, however the OP defines that, where the user may eventually recover their password.<br>
<br>Is that what you're talking about?<br><br>And this whole time I thought it was just "hey, OP, I think this user needs to change their password. Why don't you have them pick a new one and then send them back."<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 1:30 PM, Luke Shepard <span dir="ltr"><<a href="mailto:lshepard@facebook.com">lshepard@facebook.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;">
<div>
<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">If Gmail or Yahoo is an OpenID provider, and also an email provider, then resetting the password (and sending an email) does the same thing. The attacker will know they’ve been detected because the account will stop working.<br>
<br>
The question is, what should the RP do when it detects a compromised account? Today, the most common response is to reset the user’s password, and then perhaps require some additional security measures when they come back. With OpenID, there’s no way for the RP to know that the OP is controlled by the same user.<br>
<br>
This whole thing was prompted because Facebook is working to become a relying party. As part of that, we would like to be able to get this extra information. Otherwise, we are forced to have a more draconian policy – if the user’s account is compromised, then disable all OpenID logins until the user does something out of band to convince us that they control their provider. That’s pretty awkward.<br>
<br>
Publishing the account management link is useful – it lets the RP send the user to the OP to change their password if they like. But it doesn’t close the loop – there’s still no way for the RP to know whether the user has actually confirmed their account.<div>
<div></div><div class="h5"><br>
<br>
<br>
On 5/13/09 12:46 PM, "Allen Tom" <<a href="http://atom@yahoo-inc.com" target="_blank">atom@yahoo-inc.com</a>> wrote:<br>
<br>
</div></div></span></font><div><div></div><div class="h5"><blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">That's why I don't quite understand this proposal. If the RP detects<br>
that the account is possibly compromised, telling the user to change<br>
their password is very likely the same thing as informing the attacker<br>
that he's been detected. Since the attacker has the password, he might<br>
as well change the password (and the account recovery data) to lock out<br>
the original user.<br>
<br>
At any rate, having the OP publish its "Account Management" link seems<br>
to be a useful thing. For RPs that want give the user to also sign out<br>
of the OP when the user signs out of the RP could also benefit from<br>
having the OP publish its Logout link as well.<br>
<br>
Allen<br>
<br>
<br>
George Fletcher wrote:<br>
> The key is that as an RP, you have to be able to shut down "bad<br>
> accounts" and if that account is an OpenID (or any other federated<br>
> identity), then there is no way for the user (good or other wise) to<br>
> reset things. They are locked out completely. Hence, in order to<br>
> enable a good experience for users, the RP would like the OP to do<br>
> something to prove the user is really "good" before the RP will let<br>
> them back in. This does of course not protect against the attacker<br>
> going through the hoops to prove the attacker is "good", but I'd say<br>
> that's out of scope for this proposal.<br>
><br>
> Thanks,<br>
> George<br>
><br>
> Andrew Arnott wrote:<br>
>> Hi Breno,<br>
>><br>
>> But if the RP detects malicious activity, why would it ask the OP to<br>
>> have the user change their password? Isn't it too late by then, and<br>
>> wouldn't it be asking the malicious user to reset the password, thus<br>
>> locking out the real user?<br>
>><br>
>> Also, some OPs don't even use passwords to authenticate their users,<br>
>> so whatever we come up with, the extension should be able to behave<br>
>> 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<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="http://breno@google.com" target="_blank">breno@google.com</a><br>
>> <<a href="mailto:breno@google.com%3E" target="_blank">mailto: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="http://santrajan@gmail.com" target="_blank">santrajan@gmail.com</a> <<a href="mailto:santrajan@gmail.com%3E" target="_blank">mailto: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="http://general@openid.net" target="_blank">general@openid.net</a> <<a href="mailto:general@openid.net" target="_blank">mailto: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="http://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>
> _______________________________________________<br>
> general mailing list<br>
> <a href="http://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>
_______________________________________________<br>
general mailing list<br>
<a href="http://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>
</span></font></blockquote>
</div></div></div>
</blockquote></div><br>