Comments for Dossy's Blog http://dossy.org Everything that comes out of Dossy, from the strange to the banal. Fri, 06 Nov 2009 22:44:13 -0500 http://wordpress.org/?v=2.8.5 hourly 1 Comment on Terence Eden doesn’t understand the point of OAuth by ejly http://dossy.org/2009/11/terence-eden-doesnt-understand-the-point-of-oauth/comment-page-1/#comment-155924 ejly Fri, 06 Nov 2009 22:44:13 +0000 http://dossy.org/?p=857#comment-155924 Good question. I suspect the twitter user community who was accustomed to the old pre-oauth ways of dealing with authorization may expect that a password change deauthorizes everyone since that's how it used to work. But twitterers who started post-oauth probably expect that the apps are authorized separately from the password. Most other similar applications (facebook, desktop OS) authenticate apps separately from the generalized logon, sot he oauth usage twitter employs seems to be trending towards standard. OTOH, the issue with expecting apps to be booted out of access is just a legacy of the old way of doing things. Good question. I suspect the twitter user community who was accustomed to the old pre-oauth ways of dealing with authorization may expect that a password change deauthorizes everyone since that’s how it used to work. But twitterers who started post-oauth probably expect that the apps are authorized separately from the password.

Most other similar applications (facebook, desktop OS) authenticate apps separately from the generalized logon, sot he oauth usage twitter employs seems to be trending towards standard.

OTOH, the issue with expecting apps to be booted out of access is just a legacy of the old way of doing things.

]]> Comment on Terence Eden doesn’t understand the point of OAuth by Joe Steele http://dossy.org/2009/11/terence-eden-doesnt-understand-the-point-of-oauth/comment-page-1/#comment-155457 Joe Steele Thu, 05 Nov 2009 22:21:56 +0000 http://dossy.org/?p=857#comment-155457 Another question that occurred to me -- how is this different than cookies allowing access to a site when browsing? I believe it is considered a best practice to invalidate any cookies issued when the password to a site changes. I think that should apply here as well. Another question that occurred to me — how is this different than cookies allowing access to a site when browsing? I believe it is considered a best practice to invalidate any cookies issued when the password to a site changes. I think that should apply here as well.

]]> Comment on Terence Eden doesn’t understand the point of OAuth by Joe Steele http://dossy.org/2009/11/terence-eden-doesnt-understand-the-point-of-oauth/comment-page-1/#comment-155449 Joe Steele Thu, 05 Nov 2009 21:57:55 +0000 http://dossy.org/?p=857#comment-155449 I agree with that option as well. It largely depends on what the outstanding tokens allow access to in my opinion. So for example I might want to revoke tokens authorizing apps that tweet on my behalf, but maybe not tokens authorizing apps to see my profile details. I agree with that option as well. It largely depends on what the outstanding tokens allow access to in my opinion. So for example I might want to revoke tokens authorizing apps that tweet on my behalf, but maybe not tokens authorizing apps to see my profile details.

]]> Comment on Terence Eden doesn’t understand the point of OAuth by Joe Steele http://dossy.org/2009/11/terence-eden-doesnt-understand-the-point-of-oauth/comment-page-1/#comment-155448 Joe Steele Thu, 05 Nov 2009 21:48:32 +0000 http://dossy.org/?p=857#comment-155448 I would paraphrase what Terrence said a bit: Most users expect that when you change your password, having known the old password will not grant you access to the resource the new password is controlling access to. OAuth changes the landscape in this case. My analogy is this - I grant access to a bank account to my copy of Quicken. Then I find my password had been used by someone else to grant access to their copy of Quicken. I then change my password at the bank. Should the bank continue to honor Quicken transactions without requiring me to re-authorize? I think not. The only difference I see here is in the value of the transaction. Twitter being low value (to many people). The default should be to revoke the outstanding tokens, since many users will not understand the risk or be able to find the interface needed to do it themselves. I would paraphrase what Terrence said a bit: Most users expect that when you change your password, having known the old password will not grant you access to the resource the new password is controlling access to. OAuth changes the landscape in this case.

My analogy is this – I grant access to a bank account to my copy of Quicken. Then I find my password had been used by someone else to grant access to their copy of Quicken. I then change my password at the bank. Should the bank continue to honor Quicken transactions without requiring me to re-authorize? I think not.

The only difference I see here is in the value of the transaction. Twitter being low value (to many people). The default should be to revoke the outstanding tokens, since many users will not understand the risk or be able to find the interface needed to do it themselves.

]]> Comment on Terence Eden doesn’t understand the point of OAuth by Dossy Shiobara http://dossy.org/2009/11/terence-eden-doesnt-understand-the-point-of-oauth/comment-page-1/#comment-155409 Dossy Shiobara Thu, 05 Nov 2009 19:22:57 +0000 http://dossy.org/?p=857#comment-155409 Alex: That's a great analogy -- hopefully, that helps others understand why the "expected" behavior that Terence suggests is both counter-intuitive and a poor implementation decision. Alex: That’s a great analogy — hopefully, that helps others understand why the “expected” behavior that Terence suggests is both counter-intuitive and a poor implementation decision.

]]> Comment on Terence Eden doesn’t understand the point of OAuth by AlexJB http://dossy.org/2009/11/terence-eden-doesnt-understand-the-point-of-oauth/comment-page-1/#comment-155387 AlexJB Thu, 05 Nov 2009 18:21:07 +0000 http://dossy.org/?p=857#comment-155387 I agree with Havard. Changing a pwd does not, in any other context, automatically undo settings or prior actions, why should it do so in the case of OAuth? This would be like my bank canceling all of my scheduled payments when I change my website password, which I am most definitely not expecting them to do. Facebook doesn't drop all the applications that I've authorized when I change my password, and it would be a nightmare if it did. I agree with Havard. Changing a pwd does not, in any other context, automatically undo settings or prior actions, why should it do so in the case of OAuth?

This would be like my bank canceling all of my scheduled payments when I change my website password, which I am most definitely not expecting them to do. Facebook doesn’t drop all the applications that I’ve authorized when I change my password, and it would be a nightmare if it did.

]]> Comment on Terence Eden doesn’t understand the point of OAuth by Havard http://dossy.org/2009/11/terence-eden-doesnt-understand-the-point-of-oauth/comment-page-1/#comment-154963 Havard Wed, 04 Nov 2009 18:41:03 +0000 http://dossy.org/?p=857#comment-154963 The original author is confused about the difference between authentication and authorization. They are not the same thing. Authentication proves someone or something is who they say they are within some given context. In the computer world for end users, this is typically a username, which may be known by many, and a password, which should be known only by the individual. There are other methods of authentication that may be used such as key exchanges as implemented in SSL/TLS and ssh. Other systems, such as kerberos, use a weird combination of passwords, shared keys, and tokens to provide authentication. Authorization is the other piece of the puzzle. Now that you've proven you are who you say you are, what are you allowed to do? There are a variety of mechanisms to use for authorization, sometimes it's simply assuming a person with the right credentials, be it username and password or matching public/private keys, is allowed to do whatever. Other times it's providing a list of principals allowed to perform some function. I don't know enough about OAuth to go into its workings, but it is very clear that OAuth is about authorization, not authentication. The original author is confused about the difference between authentication and authorization. They are not the same thing. Authentication proves someone or something is who they say they are within some given context. In the computer world for end users, this is typically a username, which may be known by many, and a password, which should be known only by the individual. There are other methods of authentication that may be used such as key exchanges as implemented in SSL/TLS and ssh. Other systems, such as kerberos, use a weird combination of passwords, shared keys, and tokens to provide authentication.

Authorization is the other piece of the puzzle. Now that you’ve proven you are who you say you are, what are you allowed to do? There are a variety of mechanisms to use for authorization, sometimes it’s simply assuming a person with the right credentials, be it username and password or matching public/private keys, is allowed to do whatever. Other times it’s providing a list of principals allowed to perform some function. I don’t know enough about OAuth to go into its workings, but it is very clear that OAuth is about authorization, not authentication.

]]> Comment on Terence Eden doesn’t understand the point of OAuth by Andy Powell http://dossy.org/2009/11/terence-eden-doesnt-understand-the-point-of-oauth/comment-page-1/#comment-154925 Andy Powell Wed, 04 Nov 2009 17:15:54 +0000 http://dossy.org/?p=857#comment-154925 It seems to me that there are two kinds of password changes being talked about here - one in which the user is happy for authorized apps to continue working and one in which the user wants to say, "i'm worried my account has been compromised so re-authorize all previously authorized apps". It doesn't seem to me like it would be difficult to present these two, in a meaningful way, as alternative options on a password changing screen? It seems to me that there are two kinds of password changes being talked about here – one in which the user is happy for authorized apps to continue working and one in which the user wants to say, “i’m worried my account has been compromised so re-authorize all previously authorized apps”. It doesn’t seem to me like it would be difficult to present these two, in a meaningful way, as alternative options on a password changing screen?

]]> Comment on Terence Eden doesn’t understand the point of OAuth by Dossy Shiobara http://dossy.org/2009/11/terence-eden-doesnt-understand-the-point-of-oauth/comment-page-1/#comment-154897 Dossy Shiobara Wed, 04 Nov 2009 15:39:46 +0000 http://dossy.org/?p=857#comment-154897 In the case of someone compromising your Twitter account, the remedy is: 1) Change your password, thus locking the attacker out of your account. 2) Go into your authorized Twitter applications (on the Connections tab) and deauthorize any applications the attacker has authorized. Again, if you are indeed correct that “most users” (and not just you and others like you) think changing your password will deauthorize all previously authorized applications through OAuth, then this is a user education issue, one that I would fix by adding a link to the Connections setting page on the password changing page with text that explains that “changing your password does not deauthorize any previously authorized applications. To do that, go to [link to Connections page]“. I will say it outright: deauthorizing ALL OAuth tokens on a password change completely negates the value of OAuth. Period. In the case of someone compromising your Twitter account, the remedy is:

1) Change your password, thus locking the attacker out of your account.
2) Go into your authorized Twitter applications (on the Connections tab) and deauthorize any applications the attacker has authorized.

Again, if you are indeed correct that “most users” (and not just you and others like you) think changing your password will deauthorize all previously authorized applications through OAuth, then this is a user education issue, one that I would fix by adding a link to the Connections setting page on the password changing page with text that explains that “changing your password does not deauthorize any previously authorized applications. To do that, go to [link to Connections page]“.

I will say it outright: deauthorizing ALL OAuth tokens on a password change completely negates the value of OAuth. Period.

]]> Comment on Terence Eden doesn’t understand the point of OAuth by Leon http://dossy.org/2009/11/terence-eden-doesnt-understand-the-point-of-oauth/comment-page-1/#comment-154896 Leon Wed, 04 Nov 2009 15:32:39 +0000 http://dossy.org/?p=857#comment-154896 With all respect to the comments of Terence and Mr Anonymous: I am with Dossy on this one. Decoupling the use of user-id's/passwords (authentication) with autorizations is a *good* thing, and best practice. It does increase security levels and therefore should be implemented as is. What could change though, listening to the arguments by Terence and Mr A, is the proces with which Twitter, or any other OAuth supporting service, handles password changes. It would be helpfull to see a list of OAuth enabled applications after a password change, as a reminder to the user that some applications are authorized to access their profile. Such a change would be fairly easy implemented. With all respect to the comments of Terence and Mr Anonymous: I am with Dossy on this one. Decoupling the use of user-id’s/passwords (authentication) with autorizations is a *good* thing, and best practice. It does increase security levels and therefore should be implemented as is.

What could change though, listening to the arguments by Terence and Mr A, is the proces with which Twitter, or any other OAuth supporting service, handles password changes.

It would be helpfull to see a list of OAuth enabled applications after a password change, as a reminder to the user that some applications are authorized to access their profile. Such a change would be fairly easy implemented.

]]>