I am trying to implement oauth login to latest huggle, however I am confused about several things:
1) How do I obtain the data which are normally provided in a callback URL?
2) What is consumer key and secret? Can these values be shown to end-users? Do these values need to be known by application itself? If consumer secret is supposed to be known by application but not the user, how am I going to achieve that, given that user would have access to binary files which would contain it?
Thanks
Don't know the answer to 1 but,
On Thu, Sep 12, 2013 at 5:57 AM, Petr Bena benapetr@gmail.com wrote:
- What is consumer key and secret? Can these values be shown to
end-users? Do these values need to be known by application itself? If consumer secret is supposed to be known by application but not the user, how am I going to achieve that, given that user would have access to binary files which would contain it?
The secret should only be known by the application and not be given to the end users. As to how you should go about implementing this in Huggle, you can't at the moment. OAuth has methods of authentication that are made specifically for desktop applications like Huggle, but MediaWiki has yet to implement those methods.
There was a previous discussion concerning this about two weeks ago (can't find the thread at the moment), and some workarounds were also discussed. I forget if they got anywhere.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
Ok, so should we ask users for password then? Is that the only alternative in the moment?
On Thu, Sep 12, 2013 at 12:57 PM, Tyler Romeo tylerromeo@gmail.com wrote:
Don't know the answer to 1 but,
On Thu, Sep 12, 2013 at 5:57 AM, Petr Bena benapetr@gmail.com wrote:
- What is consumer key and secret? Can these values be shown to
end-users? Do these values need to be known by application itself? If consumer secret is supposed to be known by application but not the user, how am I going to achieve that, given that user would have access to binary files which would contain it?
The secret should only be known by the application and not be given to the end users. As to how you should go about implementing this in Huggle, you can't at the moment. OAuth has methods of authentication that are made specifically for desktop applications like Huggle, but MediaWiki has yet to implement those methods.
There was a previous discussion concerning this about two weeks ago (can't find the thread at the moment), and some workarounds were also discussed. I forget if they got anywhere.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Sep 12, 2013 at 8:41 AM, Petr Bena benapetr@gmail.com wrote:
Ok, so should we ask users for password then? Is that the only alternative in the moment?
Pretty much, unless Chris has a better recommended solution.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
Hi Petr,
Unfortunately, you're trying to do two things that the version of oauth we implemented doesn't do very well. OAuth 1 enabled users on website A to safely grant website A access to specific resources on website B. Any other use, you have to be very careful to ensure that the the protocol is giving you the security properties that you think it is.
As noted earlier, using our OAuth 1 implementation with desktop apps will not work for the typical case because the Consumer (App specific) secret is assumed to be secret only to the App owner who registered the App. So registering your app and distributing the private rsa key or secret in the binary is not safe. However, if you have your users go to the Consumer registration page (over https), register as a unique consumer, and then authorize there app to use Wikipedia, that would work-- it's just two slightly complicated steps instead of a single, easy step to do the authorization.
You also mentioned logging in with OAuth. I'm not sure if that was in the genetic sense of you App doing stuff as the user, or if you really have a central concept of each user and want to know for sure that one of your App users really is a particular Wikipedia user. If it's the later, this is a common misconception about the protocol. OAuth 1 (as specified) is not safe to use for logins. Twitter modified the protocol into xAuth, and Facebook uses the openID extension to OAuth 2 to provide safe logins. For basic OAuth though, there is a well known attack where another OAuth consumer can use the secrets that they know (from users authorizing their App) to trick your App into thinking they are someone else. Our implementation tries to prevent this attack, but if you're using the protocol in a way it wasn't designed for, your likely to be attacked in new ways in the future. So I would caution against it.
We are going to turn on openID in the bes near future, which DOES let you authenticate users, so may be a possibility.
Sorry for the bad news, but thanks for asking. If this seems to be a common scenario, then we'll prioritize something like OAuth 2 + OpenID connect in the future.
On Sep 12, 2013 6:57 AM, "Tyler Romeo" tylerromeo@gmail.com wrote:
On Thu, Sep 12, 2013 at 8:41 AM, Petr Bena benapetr@gmail.com wrote:
Ok, so should we ask users for password then? Is that the only alternative in the moment?
Pretty much, unless Chris has a better recommended solution.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.or
On Thu, Sep 12, 2013 at 2:57 AM, Petr Bena benapetr@gmail.com wrote:
I am trying to implement oauth login to latest huggle, however I am confused about several things:
- How do I obtain the data which are normally provided in a callback URL?
If your app doesn't have a sensible callback URL, you can use the URL of Special:MWOAuth/verified. This page will display the verification code to the user with instructions to copy it into your application.
- What is consumer key and secret? Can these values be shown to
end-users? Do these values need to be known by application itself? If consumer secret is supposed to be known by application but not the user, how am I going to achieve that, given that user would have access to binary files which would contain it?
As already noted, the secret is supposed to be known by the application but not the end user, which is a problem for desktop apps.
I'm personally still not clear on how OAuth 2 solves this problem, unless it's just by saying "you must use HTTPS, and don't assume that the consumer secret is really secret". Which we could well enough do with our OAuth 1.0a implementation, couldn't we?
On Thu, Sep 12, 2013 at 12:00 PM, Brad Jorsch (Anomie) < bjorsch@wikimedia.org> wrote:
I'm personally still not clear on how OAuth 2 solves this problem, unless it's just by saying "you must use HTTPS, and don't assume that the consumer secret is really secret". Which we could well enough do with our OAuth 1.0a implementation, couldn't we?
It does so by not using the client secret in the first place. Keep in mind that client authentication is made to solve a very specific problem in OAuth: authorization grant and refresh token security. If you think about it, there's no big need for client authentication normally: resource owners have to explicitly grant access, so clients are acting on the resource owner's behalf in the first place.
The main time client authentication becomes important is in the case of authorization grants, because they are secrets that are transmitted over the network to the client, and thus may be subject to compromise. Since client secrets are not transmitted over the network (assuming you're not using the bearer token authentication), they allow verification that the client actually owns the authorization grant in question.
The same goes for refresh tokens, and refresh tokens allow basically unlimited access, so if they are compromised it's a much bigger problem than if an access token is compromised. The purpose of client authentication in the case of refresh tokens is to make sure even if a refresh token is compromised, the attacker would still have to obtain the client secret before being able to use it. The other reason is to enable rotation of client credentials, which would otherwise require revocation of all the client's refresh tokens.
Getting to the actual question, OAuth 2.0 uses the Implicit authorization flow for desktop and browser based applications. This flow does not have authorization grants, and does not allow refresh tokens, so all of the reasons for client authentication are moot. Also, unlike other clients, desktop-based clients are within the user's control. So unlike an external client, where the only method the resource owner has of controlling it is to revoke it at the authorization server, the resource owner can just close the application and be done with it.
Of course, this is not perfect. There is still the attack where the access token itself is compromised, or where a rogue client gives access tokens to other clients. The latter case is mitigated by the fact that access tokens are short-lived, so the application with only have access for a brief period of time (not much of an excuse, since you can do a lot in an hour, but nonetheless better than persistent access). But keep in mind the user decided to trust the application in the first place. The former case is mitigated by TLS, since there really is no other way of protecting nonce secrets other than just encrypting them.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
Sounds cool. When is it going to be available for developers on production?
On Thu, Sep 12, 2013 at 8:03 PM, Tyler Romeo tylerromeo@gmail.com wrote:
On Thu, Sep 12, 2013 at 12:00 PM, Brad Jorsch (Anomie) < bjorsch@wikimedia.org> wrote:
I'm personally still not clear on how OAuth 2 solves this problem, unless it's just by saying "you must use HTTPS, and don't assume that the consumer secret is really secret". Which we could well enough do with our OAuth 1.0a implementation, couldn't we?
It does so by not using the client secret in the first place. Keep in mind that client authentication is made to solve a very specific problem in OAuth: authorization grant and refresh token security. If you think about it, there's no big need for client authentication normally: resource owners have to explicitly grant access, so clients are acting on the resource owner's behalf in the first place.
The main time client authentication becomes important is in the case of authorization grants, because they are secrets that are transmitted over the network to the client, and thus may be subject to compromise. Since client secrets are not transmitted over the network (assuming you're not using the bearer token authentication), they allow verification that the client actually owns the authorization grant in question.
The same goes for refresh tokens, and refresh tokens allow basically unlimited access, so if they are compromised it's a much bigger problem than if an access token is compromised. The purpose of client authentication in the case of refresh tokens is to make sure even if a refresh token is compromised, the attacker would still have to obtain the client secret before being able to use it. The other reason is to enable rotation of client credentials, which would otherwise require revocation of all the client's refresh tokens.
Getting to the actual question, OAuth 2.0 uses the Implicit authorization flow for desktop and browser based applications. This flow does not have authorization grants, and does not allow refresh tokens, so all of the reasons for client authentication are moot. Also, unlike other clients, desktop-based clients are within the user's control. So unlike an external client, where the only method the resource owner has of controlling it is to revoke it at the authorization server, the resource owner can just close the application and be done with it.
Of course, this is not perfect. There is still the attack where the access token itself is compromised, or where a rogue client gives access tokens to other clients. The latter case is mitigated by the fact that access tokens are short-lived, so the application with only have access for a brief period of time (not much of an excuse, since you can do a lot in an hour, but nonetheless better than persistent access). But keep in mind the user decided to trust the application in the first place. The former case is mitigated by TLS, since there really is no other way of protecting nonce secrets other than just encrypting them.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Sep 12, 2013 at 11:31 AM, Petr Bena benapetr@gmail.com wrote:
Sounds cool. When is it going to be available for developers on production?
OAuth2 (which Tyler was referencing) will not be implemented in the next few months. It's unfortunately a fairly complex implementation, that requires making security tradeoffs that I wouldn't feel comfortable rushing.
Anomie and I were talking last night about possibly allowing Consumers to flag themselves as desktop apps that we'll tag with a generic tag instead of a consumer-specific tag. That would take a step towards possibly even allowing desktop applications to register themselves over the api using the user's credentials, send the user through the normal authorization flow to approve the consumer that they "own", and basically make a simple process to essentially exchange their username/password for an authorized token.
This of course means that we would condone users giving their username/password to a potentially trojaned desktop application, for the benefit that honest apps would be able to easily store a token instead of the username/password combination and prevent a later attacker from getting full access to a user's account through their password.
Does the community feel like that's a reasonable tradeoff?
On Thu, Sep 12, 2013 at 8:03 PM, Tyler Romeo tylerromeo@gmail.com wrote:
On Thu, Sep 12, 2013 at 12:00 PM, Brad Jorsch (Anomie) < bjorsch@wikimedia.org> wrote:
I'm personally still not clear on how OAuth 2 solves this problem, unless it's just by saying "you must use HTTPS, and don't assume that the consumer secret is really secret". Which we could well enough do with our OAuth 1.0a implementation, couldn't we?
It does so by not using the client secret in the first place. Keep in
mind
that client authentication is made to solve a very specific problem in OAuth: authorization grant and refresh token security. If you think about it, there's no big need for client authentication normally: resource
owners
have to explicitly grant access, so clients are acting on the resource owner's behalf in the first place.
The main time client authentication becomes important is in the case of authorization grants, because they are secrets that are transmitted over the network to the client, and thus may be subject to compromise. Since client secrets are not transmitted over the network (assuming you're not using the bearer token authentication), they allow verification that the client actually owns the authorization grant in question.
The same goes for refresh tokens, and refresh tokens allow basically unlimited access, so if they are compromised it's a much bigger problem than if an access token is compromised. The purpose of client authentication in the case of refresh tokens is to make sure even if a refresh token is compromised, the attacker would still have to obtain the client secret before being able to use it. The other reason is to enable rotation of client credentials, which would otherwise require revocation
of
all the client's refresh tokens.
Getting to the actual question, OAuth 2.0 uses the Implicit authorization flow for desktop and browser based applications. This flow does not have authorization grants, and does not allow refresh tokens, so all of the reasons for client authentication are moot. Also, unlike other clients, desktop-based clients are within the user's control. So unlike an
external
client, where the only method the resource owner has of controlling it is to revoke it at the authorization server, the resource owner can just
close
the application and be done with it.
Of course, this is not perfect. There is still the attack where the
access
token itself is compromised, or where a rogue client gives access tokens
to
other clients. The latter case is mitigated by the fact that access
tokens
are short-lived, so the application with only have access for a brief period of time (not much of an excuse, since you can do a lot in an hour, but nonetheless better than persistent access). But keep in mind the user decided to trust the application in the first place. The former case is mitigated by TLS, since there really is no other way of protecting nonce secrets other than just encrypting them.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Sep 13, 2013 at 11:13 AM, Chris Steipp csteipp@wikimedia.orgwrote:
This of course means that we would condone users giving their username/password to a potentially trojaned desktop application, for the benefit that honest apps would be able to easily store a token instead of the username/password combination and prevent a later attacker from getting full access to a user's account through their password.
Does the community feel like that's a reasonable tradeoff?
I have another idea: application passwords. Google has them. Facebook has them. And they're basically like OAuth tokens except a bit more permanent.
For those not familiar with the concept, Google and others have a section in your account settings that allow you to generate application passwords. You then give this password to the application in lieu of your actual password. Of course, it can be revoked at any time, and it'd be trivial to implement scoping on these application passwords. If anything we could just have them act exactly like OAuth access tokens.
While I do think that there is definitely a bit of trust that goes into giving an application access to your account, there are definitely methods we could employ to avoid letting users give their password directly to an application.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Fri, Sep 13, 2013 at 8:38 AM, Tyler Romeo tylerromeo@gmail.com wrote:
On Fri, Sep 13, 2013 at 11:13 AM, Chris Steipp <csteipp@wikimedia.org
wrote:
This of course means that we would condone users giving their username/password to a potentially trojaned desktop application, for the benefit that honest apps would be able to easily store a token instead of the username/password combination and prevent a later attacker from
getting
full access to a user's account through their password.
Does the community feel like that's a reasonable tradeoff?
I have another idea: application passwords. Google has them. Facebook has them. And they're basically like OAuth tokens except a bit more permanent.
It's definitely something to consider. I don't want to create too many different authentication schemes, since that means someone who has a fair amount of security understanding will need to maintain them long term. But, I definitely see the use for them, and they could probably plug into MediaWiki exactly like OAuth.
Of course the drawback of them vs OAuth is that the password still needs to be secret (so only submitted over https), whereas having the consumer secret really secret lets the consumer ensure integrity of the message over http. But again, that really only would affect users where https is restricted.
For those not familiar with the concept, Google and others have a section in your account settings that allow you to generate application passwords. You then give this password to the application in lieu of your actual password. Of course, it can be revoked at any time, and it'd be trivial to implement scoping on these application passwords. If anything we could just have them act exactly like OAuth access tokens.
While I do think that there is definitely a bit of trust that goes into giving an application access to your account, there are definitely methods we could employ to avoid letting users give their password directly to an application.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org