[oauth] Re: Using OAuth as SSO
On Mar 26, 4:39 pm, Chris Messina chris.mess...@gmail.com wrote: Why don't you want to do OpenID? The problem is that we are currently using CAS as our SSO, and since we are a large university invested in CAS, we cannot easily switch to OpenID. If we use OpenID, then a user would have to login to our system using CAS, and if they wanted to login to gmail, then they would have to authenticate with OpenID - this would sort of negate single sign-on, since the user would have to login twice. OAuth would allow us to keep a token on our side, and the user would only need to authenticate twice when they allow us access to their account using OAuth. -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
[oauth] Re: Using OAuth as SSO
I'd still like to know if there are any examples of SSO using OAuth to sign into gmail - I have found some examples for use with Twitter, but not Google. On Mar 29, 11:31 am, Adam apcau...@gmail.com wrote: On Mar 26, 4:39 pm, Chris Messina chris.mess...@gmail.com wrote: Why don't you want to do OpenID? The problem is that we are currently using CAS as our SSO, and since we are a large university invested in CAS, we cannot easily switch to OpenID. If we use OpenID, then a user would have to login to our system using CAS, and if they wanted to login to gmail, then they would have to authenticate with OpenID - this would sort of negate single sign-on, since the user would have to login twice. OAuth would allow us to keep a token on our side, and the user would only need to authenticate twice when they allow us access to their account using OAuth. -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
[oauth] Using OAuth as SSO
We currently use CAS for SSO. I'd like to have SSO into gmail, but do not want to switch to OpenID. Is it possible to use OAuth to login users into their gmail accounts? Or is OAuth only meant to retrieve user data? I am currently using SignPost to connect to OAuth... if it matters. Thanks. -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
[oauth] Re: My case against section 6.2.1 (User redirection)
My understanding is that you do not want to even prompt the user for their username and password. Effectively you want to set up a, as mentioned before, valet credential system. It's not the real key, just enough to make the car go. To that end we have taken an approach of letting the user know that they can link their account to alternate services. In order to allow that, they have to create a credential they that is not their username or password. It's an extra step for the user to be sure. But it communicates to the user that: 1) Other systems are available in the world that might ask for this credential 2) This credential is not their username or password, so the core of their account is safe, and they will only be asked for their username and password on our site. It also ensures that the worst a phisher could get is partial account access, assuming the partial information is not sensitive, all is well. Granted, someone could just spoof the site, but that is a threat no matter what, at some point the user has to take responsibility for themselves. I don't leave my credit cards laying around in public overnight assuming everything will be fine. That's my 2 cents though. I don't have a problem with the redirect. On Wed, Sep 30, 2009 at 12:15 PM, Sunir Shah su...@freshbooks.com wrote: I have a stupid question. When I hit the authorization page, Flickr claims it is a trusted Yahoo! application. How does Flickr know that? Is it relying on the consumer key and secret? My impression is that those could be compromised in a heartbeat. Or is it doing something more clever? Cheers, Sunir Shah, Chief Handshaker, FreshBooks (416) 481-6946 x224 http://www.freshbooks.com/team/sunir http://twitter.com/sunir On 30-Sep-09, at 11:27 AM, Blaine Cook wrote: I'd love to see some data on adoption of the Flickr iPhone app; it does the right thing security-wise and does not ask for a username / password, even though it's the native Flickr app running on a highly controlled platform --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Oauth automated integration
I am interested in the same thing, 2-Legged OAuth. The link to that thread appears to be missing? Could you repost it?Or is 2-Legged OAuth, just regualr OAuth sans the Auth tokens step?, eg Consumer just Signs requests to the Service Provider, no middle step. On Fri, Jul 24, 2009 at 6:18 AM, Aditya aditya.gollak...@gmail.com wrote: Thanks for all your assistance. I've managed to get this working using 2 legged OAuth. Regards, Aditya On Jul 22, 1:51 am, Richard Wallace rwallace1...@gmail.com wrote: What you want is 2-legged OAuth. There was a recent thread[1] discussing it and if you Google it you'll find lots of other information about using it. Rich [1] http://groups.google.com/group/oauth/browse_thread/thread/9738dc9afdc... On Tue, Jul 21, 2009 at 2:49 AM, Antonio Hinojoantoniohm2...@gmail.com wrote: In fact I think it is neccesary that the user can login in the web site and validate the token. This step is the key in my opinion to avoid pishing for example, 2009/7/21 Andrew Badera and...@badera.us On Tue, Jul 21, 2009 at 1:06 AM, Aditya aditya.gollak...@gmail.com wrote: Hi All, I'm trying to integrate 2 applications and need to use Oauth for one of them (Get Satisfaction). I'm using Mule as my transport layer. From what I've read, it seems like you need to access a browser and approve the authorisation before you can get a token to use for the api calls. The whole point of my integration is to make it automatic without any human intervention. Is there any sample code that can assist is creating the token via web services as a consumer? Thanks in advance Aditya A large part of the point of OAuth protocol, in my limited understanding, is the critical step of human confirmation of access. Thanks- - Andy Badera - and...@badera.us - Google me:http://www.google.com/search?q=andrew+badera - This email is: [ ] bloggable [x] ask first [ ] private --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: How should I distinguish between approved or denied authorization?
I think you send a 401 error... http://lmgtfy.com/?q=Error+401 On Apr 27, 11:42 pm, mdub mdu...@gmail.com wrote: Section 6.2.3 of the spec says: If the User denies access, the Consumer MAY be notified that the Request Token has been revoked. How does one typically indicate, in the authorization callback, whether the Request Token was approved or denied? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: One-time only token exchange?
I agree. The Request Token has never been exchanged for an Access Token. isn't explicitly saying one-time only token, but I believe that is what was intended. Clarifying this line would be sufficient as would requiring the Service Provider log the User out after any request token attempt. This forces the User to login to the Service Provider to start the process of requesting access all over. On Apr 28, 3:13 pm, Leah Culver leah.cul...@gmail.com wrote: Actually, I think it's a pretty small change to the spec. In section 6.3.2 Service Provider Grants an Access Token (http://oauth.net/core/1.0/#auth_step3), it says: The Service Provider MUST ensure that: - The request signature has been successfully verified. - The Request Token has never been exchanged for an Access Token. - The Request Token matches the Consumer Key. ... If the request fails verification or is rejected for other reasons, the Service Provider SHOULD respond with the appropriate response code as defined in HTTP Response Codes (HTTP Response Codes)http://oauth.net/core/1.0/#http_codes . Perhaps an updated version could say something like (changes in red): The Service Provider MUST ensure that: - The request signature has been successfully verified. - The Request Token has never been exchanged for an Access Token. - There have been no prior attempts to exchange this Request Token for an Access Token. - The Request Token matches the Consumer Key. ... If the request fails verification or is rejected for other reasons, the Service Provider SHOULD invalidate or delete the request token and respond with the appropriate response code as defined in HTTP Response Codes (HTTP Response Codes) http://oauth.net/core/1.0/#http_codes. On Tue, Apr 28, 2009 at 3:02 PM, Leah Culver leah.cul...@gmail.com wrote: Hmm... I feel like this has been lost in all the hubbub about callbacks. I strongly advocate saying something in the spec about making the token exchange (access token endpoint) one-time use only. By one-time only, I mean that the first time there is an attempt to exchange a request token for an access token, if the request token has not been authorized, then that request token should be marked as invalid. This will make a session fixation attack nearly impossible without a callback. If a service provider allows multiple attempts to exchange the request token a callback is not even necessary for the attack to work! The attacker must only keep trying to exchange the token. I know it's up to the service provider to implement one-time only token exchange, but putting it in the documentation (and libraries) will make it much easier for service providers to do the right thing. Am I missing the discussion about this? Is it on the wiki and I just can't find it? Or is everyone in agreement that this should be added to the docs? Thanks, Leah --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: San Francisco meetup this Tuesday 5pm
I can make it. On Apr 24, 6:12 pm, Leah Culver leah.cul...@gmail.com wrote: Hey, On Fri, Apr 24, 2009 at 5:52 PM, Manish Pandit pandit.man...@gmail.comwrote: On Apr 24, 2:42 pm, Leah Culver leah.cul...@gmail.com wrote: Hi all, My eyes hurt from trying to read long email threads. There's quite a few good ideas for helping protect against the current security issue and it will be helpful to get together to discuss. Here's the details: OAuth Meetup Tuesday, Apr 28th at 5pm Six Apart 548 4th Street I'll try to get the conference call stuff working too - more about this later. Sorry for the short notice! I'll try to summarize the meeting and get the notes back in the mailing list or wiki. Leah Thanks Leah for taking the initiative. I was wondering if some of us could meet at RSA Conference at SF but since today was the last day, I did not bother posting it. It'd be great if a conference call could be worked out due to location logistics, or future meetings (non-rush ones) can be done on Fridays/ Saturdays.. -cheers, Manish We could have it this weekend instead... I'm actually pretty flexible on the date. Can anyone actually make it on Tuesday? Leah --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
I just wrote a long post that just disappeared. Hmm. Testing... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
The idea is that the communication between the Consumer and Provider sites consist of urls that are composed behind user logins ON BOTH SITES at the same time. I believe that this prevents simpler attacks like man in the middle or DNS or url tampering and allows secure token generation based on session authentication, which, when employed properly, cannot be spoofed from either end or the middle. On Apr 25, 11:21 am, Josh Roesslein jroessl...@gmail.com wrote: I don't really see the need for the double trip to the service provider to perform the login and authorization. This can be done in one single step like I have outlined in my proposal. User logs into provider, grants access, and returns back with the token. The less work we do in our flow the less likely an attacker can find a hole. The double trip just creates a second chance for an attack. On Sat, Apr 25, 2009 at 12:33 PM, J. Adam Moore jadammo...@gmail.comwrote: I'm writing a blog post to explain why I think I have a solution, but I believe it is as simple as moving the provider login to before the consumer token generation which is triggered by a provider-side redirect. This is simply playing keep-away with redirects, but it arguably works if your goal is web-based sudo permissions for an app or site. 1) User clicks on Consumer site link to Provider (no tokens or anything, just a request for a protected area on the site that IDs the Consumer) 2) Link is protected, requires login. (This should generate your session/user identifier) 3) Once logged in user is redirected (with a unique identifier, encrypted or not) back to a Consumer redirect page 4) Consumer generates request token and automatically redirects back to Provider's user authorization page 5) User approves access, Provider automatically logs user out, callbacks are optional. 6) Desktop apps can use a one-time-only password-reset-style cut-n- paste token IN THE NORMAL PASSWORD FIELD to authenticate. There are many suggestions that duplicate tokens, information, or steps in the process. If the initial association of the process with a user is the problem, then requiring a login first will ALWAYS be the solution. The flow is fine as it is, with the small exception that the provider-side login requirement needs to be moved up in the process. The game of keep-away doesn't hinge on obfuscation of the McGuffin, but in passing it outside of the reach of the attacker. If an attacker can use redirects to jump into the position of a player, then we can use redirects to never pass the McGuffin to the same position with the same info. As far as I can tell there was only one INSIGNIFICANT flaw with OAuth and that was the Provider login requirement happening too late. That's it. Once you do that you can check the session or user, send nonces or encrypted user_ids with the initial redirect, or just about any crazy security measure you can think up. Steps 3,4,and 5 are invisible to the user and end with a token that can be used as a temporary password which triggers token authorization and association with a seamless manual option that appears to jump straight to step 6. Because all of this is happening behind a Provider login, it is as secure as you're going to get it without fundamentally changing the structure of the whole process. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
Logically I find that the only way to guarantee that two different users at two different sites are really the same person is to make them self authenticate BEFORE establishing a secure communication. By having both the Provider and Consumer redirect to a spot behind a login on both sites it fulfills this requirement without breaking the current model or people's brains. Making something simpler for the sake of simplicity is simply not a compelling argument against requiring habeas corpus at each end. I think too many people are trying to adjust the model instead of the implementation. The model is fine once you can prove (on each end) that it is the same user. Not caring what your login is on the consumer? What does that even mean? Either the redirect url is publicly accessible or it requires a login. I don't need to know WHO you are or care if you are logged in or not, but nothing is going to happen until you prove that you are who you are trying to associate with. This also leaves sites able to craft their redirect urls to contain either unique paths or unique tokens or both without breaking the protocol or damaging the current information exchange model. I still favor a solution that doesn't add or take away anything from the current model. Basically a protocol that reorders passing information to occur after user authentication and tightens rules on where redirects point. On Apr 25, 12:12 pm, Josh Roesslein jroessl...@gmail.com wrote: We don't really need the user to be logged into the consumer to generate our token. The service provider should not care what our login is on the consumer. All it cares about is authorizing a consumer access to our data. We log into the provider and authorize the creation of an access token for the consumer. We then visit this consumer and hand over our token (either manually for desktop apps or by being redirect by a callback w/ token attached). The consumer can now access our data. It is up to the consumer now on how to store this token. (Here is a link to the flow:http://pastie.org/pastes/457478) I don't think preventing middle attacks or phishing is really what oauth should be doing. SSL does this well and it should be used for the transfer of the token from the provider to the consumer. This way an attacker can't intercept the token and use it to log in to the consumer under their account and access our data on our provider account. The user can't be easily phished since both URL's (authorization URL and callback URL) are verifiable by SSL. Also the callback is either stored on the service provider or signed in the authorization request by the consumer. On Sat, Apr 25, 2009 at 1:43 PM, J. Adam Moore jadammo...@gmail.com wrote: The idea is that the communication between the Consumer and Provider sites consist of urls that are composed behind user logins ON BOTH SITES at the same time. I believe that this prevents simpler attacks like man in the middle or DNS or url tampering and allows secure token generation based on session authentication, which, when employed properly, cannot be spoofed from either end or the middle. On Apr 25, 11:21 am, Josh Roesslein jroessl...@gmail.com wrote: I don't really see the need for the double trip to the service provider to perform the login and authorization. This can be done in one single step like I have outlined in my proposal. User logs into provider, grants access, and returns back with the token. The less work we do in our flow the less likely an attacker can find a hole. The double trip just creates a second chance for an attack. On Sat, Apr 25, 2009 at 12:33 PM, J. Adam Moore jadammo...@gmail.com wrote: I'm writing a blog post to explain why I think I have a solution, but I believe it is as simple as moving the provider login to before the consumer token generation which is triggered by a provider-side redirect. This is simply playing keep-away with redirects, but it arguably works if your goal is web-based sudo permissions for an app or site. 1) User clicks on Consumer site link to Provider (no tokens or anything, just a request for a protected area on the site that IDs the Consumer) 2) Link is protected, requires login. (This should generate your session/user identifier) 3) Once logged in user is redirected (with a unique identifier, encrypted or not) back to a Consumer redirect page 4) Consumer generates request token and automatically redirects back to Provider's user authorization page 5) User approves access, Provider automatically logs user out, callbacks are optional. 6) Desktop apps can use a one-time-only password-reset-style cut-n- paste token IN THE NORMAL PASSWORD FIELD to authenticate. There are many suggestions that duplicate tokens, information, or steps in the process. If the initial association of the process with a user is the problem
[oauth] Re: OAuth Security Advisory
What I should have added was that using my solution, the consumer is completely capable of being stupid and giving the consumer a redirect that doesn't require a login on the consumer side, but they can also take a gun and blow their brains out. You can't stop people from being stupid and it's not the Providers job to even care if the redirect they were given is secure. I'll say it again. I AM NOT CHANGING THE OAUTH MODEL. Everything works exactly as before EXCEPT the request token HAPPENS AFTER AUTHENTICATION ON THE PROVIDER SIDE. That is all. That fixes everything. Triggering the authentication flow AS IT IS NOW from behind a login ON THE PROVIDER SIDE. An attacker cannot generate a reusable token or spoof/calculate an access token. Totally secure would be the scenario I explained where both sites redirect behind a login. It's simple. It's easy. Lets do it. On Apr 25, 12:41 pm, J. Adam Moore jadammo...@gmail.com wrote: Logically I find that the only way to guarantee that two different users at two different sites are really the same person is to make them self authenticate BEFORE establishing a secure communication. By having both the Provider and Consumer redirect to a spot behind a login on both sites it fulfills this requirement without breaking the current model or people's brains. Making something simpler for the sake of simplicity is simply not a compelling argument against requiring habeas corpus at each end. I think too many people are trying to adjust the model instead of the implementation. The model is fine once you can prove (on each end) that it is the same user. Not caring what your login is on the consumer? What does that even mean? Either the redirect url is publicly accessible or it requires a login. I don't need to know WHO you are or care if you are logged in or not, but nothing is going to happen until you prove that you are who you are trying to associate with. This also leaves sites able to craft their redirect urls to contain either unique paths or unique tokens or both without breaking the protocol or damaging the current information exchange model. I still favor a solution that doesn't add or take away anything from the current model. Basically a protocol that reorders passing information to occur after user authentication and tightens rules on where redirects point. On Apr 25, 12:12 pm, Josh Roesslein jroessl...@gmail.com wrote: We don't really need the user to be logged into the consumer to generate our token. The service provider should not care what our login is on the consumer. All it cares about is authorizing a consumer access to our data. We log into the provider and authorize the creation of an access token for the consumer. We then visit this consumer and hand over our token (either manually for desktop apps or by being redirect by a callback w/ token attached). The consumer can now access our data. It is up to the consumer now on how to store this token. (Here is a link to the flow:http://pastie.org/pastes/457478) I don't think preventing middle attacks or phishing is really what oauth should be doing. SSL does this well and it should be used for the transfer of the token from the provider to the consumer. This way an attacker can't intercept the token and use it to log in to the consumer under their account and access our data on our provider account. The user can't be easily phished since both URL's (authorization URL and callback URL) are verifiable by SSL. Also the callback is either stored on the service provider or signed in the authorization request by the consumer. On Sat, Apr 25, 2009 at 1:43 PM, J. Adam Moore jadammo...@gmail.com wrote: The idea is that the communication between the Consumer and Provider sites consist of urls that are composed behind user logins ON BOTH SITES at the same time. I believe that this prevents simpler attacks like man in the middle or DNS or url tampering and allows secure token generation based on session authentication, which, when employed properly, cannot be spoofed from either end or the middle. On Apr 25, 11:21 am, Josh Roesslein jroessl...@gmail.com wrote: I don't really see the need for the double trip to the service provider to perform the login and authorization. This can be done in one single step like I have outlined in my proposal. User logs into provider, grants access, and returns back with the token. The less work we do in our flow the less likely an attacker can find a hole. The double trip just creates a second chance for an attack. On Sat, Apr 25, 2009 at 12:33 PM, J. Adam Moore jadammo...@gmail.com wrote: I'm writing a blog post to explain why I think I have a solution, but I believe it is as simple as moving the provider login to before the consumer token generation which is triggered by a provider-side redirect. This is simply playing keep-away
[oauth] Re: OAuth Security Advisory
EDIT LAST POST: The second consumer I meant to say provider. On Apr 25, 12:55 pm, J. Adam Moore jadammo...@gmail.com wrote: What I should have added was that using my solution, the consumer is completely capable of being stupid and giving the consumer a redirect that doesn't require a login on the consumer side, but they can also take a gun and blow their brains out. You can't stop people from being stupid and it's not the Providers job to even care if the redirect they were given is secure. I'll say it again. I AM NOT CHANGING THE OAUTH MODEL. Everything works exactly as before EXCEPT the request token HAPPENS AFTER AUTHENTICATION ON THE PROVIDER SIDE. That is all. That fixes everything. Triggering the authentication flow AS IT IS NOW from behind a login ON THE PROVIDER SIDE. An attacker cannot generate a reusable token or spoof/calculate an access token. Totally secure would be the scenario I explained where both sites redirect behind a login. It's simple. It's easy. Lets do it. On Apr 25, 12:41 pm, J. Adam Moore jadammo...@gmail.com wrote: Logically I find that the only way to guarantee that two different users at two different sites are really the same person is to make them self authenticate BEFORE establishing a secure communication. By having both the Provider and Consumer redirect to a spot behind a login on both sites it fulfills this requirement without breaking the current model or people's brains. Making something simpler for the sake of simplicity is simply not a compelling argument against requiring habeas corpus at each end. I think too many people are trying to adjust the model instead of the implementation. The model is fine once you can prove (on each end) that it is the same user. Not caring what your login is on the consumer? What does that even mean? Either the redirect url is publicly accessible or it requires a login. I don't need to know WHO you are or care if you are logged in or not, but nothing is going to happen until you prove that you are who you are trying to associate with. This also leaves sites able to craft their redirect urls to contain either unique paths or unique tokens or both without breaking the protocol or damaging the current information exchange model. I still favor a solution that doesn't add or take away anything from the current model. Basically a protocol that reorders passing information to occur after user authentication and tightens rules on where redirects point. On Apr 25, 12:12 pm, Josh Roesslein jroessl...@gmail.com wrote: We don't really need the user to be logged into the consumer to generate our token. The service provider should not care what our login is on the consumer. All it cares about is authorizing a consumer access to our data. We log into the provider and authorize the creation of an access token for the consumer. We then visit this consumer and hand over our token (either manually for desktop apps or by being redirect by a callback w/ token attached). The consumer can now access our data. It is up to the consumer now on how to store this token. (Here is a link to the flow:http://pastie.org/pastes/457478) I don't think preventing middle attacks or phishing is really what oauth should be doing. SSL does this well and it should be used for the transfer of the token from the provider to the consumer. This way an attacker can't intercept the token and use it to log in to the consumer under their account and access our data on our provider account. The user can't be easily phished since both URL's (authorization URL and callback URL) are verifiable by SSL. Also the callback is either stored on the service provider or signed in the authorization request by the consumer. On Sat, Apr 25, 2009 at 1:43 PM, J. Adam Moore jadammo...@gmail.com wrote: The idea is that the communication between the Consumer and Provider sites consist of urls that are composed behind user logins ON BOTH SITES at the same time. I believe that this prevents simpler attacks like man in the middle or DNS or url tampering and allows secure token generation based on session authentication, which, when employed properly, cannot be spoofed from either end or the middle. On Apr 25, 11:21 am, Josh Roesslein jroessl...@gmail.com wrote: I don't really see the need for the double trip to the service provider to perform the login and authorization. This can be done in one single step like I have outlined in my proposal. User logs into provider, grants access, and returns back with the token. The less work we do in our flow the less likely an attacker can find a hole. The double trip just creates a second chance for an attack. On Sat, Apr 25, 2009 at 12:33 PM, J. Adam Moore jadammo...@gmail.com wrote: I'm writing a blog post
[oauth] Re: OAuth Security Advisory
I think you are putting all your faith in to the security of the information and not realizing the insecurity of the urls and redirection. Why can't I act as a proxy for the unwitting user who goes through your whole scenario only to find that his secure authenticated token has been poached by my simply framing a consumer site or passing your actions through cUrl requests from my site? You are hacking away at the problem but I don't think you truly grok it. You simply recreated it in a more complicated form. So I can't phish you one way, but you left it wide open for everything else. I'll say it for anyone new to the conversation: PHISHING is why we are here discussing this. Not better encryption protocols, but implementation people, implementation. On Apr 25, 1:14 pm, Josh Roesslein jroessl...@gmail.com wrote: How would you phish that? Provide a step by step example. On Sat, Apr 25, 2009 at 3:11 PM, J. Adam Moore jadammo...@gmail.com wrote: I could Phish the hell out of that. Pop up windows and timed out requests sound like a user nightmare. Not to mention all the extra checking and processing of info. It seems rather hackish. I really think you are over complicating this. The problem itself is REALLY specific: Phishing. Like fish in a barrel phishing. The solution is to take away their bullets, and is not to try and harden the barrels or educate the fish to dodge bullets. On Apr 25, 1:01 pm, Josh Roesslein jroessl...@gmail.com wrote: I am not suggesting changing the entire spec, just dropping the request token part. This is what I'm getting at -- https://oauth.pbwiki.com/Signed-Approval-URLs On Sat, Apr 25, 2009 at 2:58 PM, J. Adam Moore jadammo...@gmail.com wrote: EDIT LAST POST: The second consumer I meant to say provider. On Apr 25, 12:55 pm, J. Adam Moore jadammo...@gmail.com wrote: What I should have added was that using my solution, the consumer is completely capable of being stupid and giving the consumer a redirect that doesn't require a login on the consumer side, but they can also take a gun and blow their brains out. You can't stop people from being stupid and it's not the Providers job to even care if the redirect they were given is secure. I'll say it again. I AM NOT CHANGING THE OAUTH MODEL. Everything works exactly as before EXCEPT the request token HAPPENS AFTER AUTHENTICATION ON THE PROVIDER SIDE. That is all. That fixes everything. Triggering the authentication flow AS IT IS NOW from behind a login ON THE PROVIDER SIDE. An attacker cannot generate a reusable token or spoof/calculate an access token. Totally secure would be the scenario I explained where both sites redirect behind a login. It's simple. It's easy. Lets do it. On Apr 25, 12:41 pm, J. Adam Moore jadammo...@gmail.com wrote: Logically I find that the only way to guarantee that two different users at two different sites are really the same person is to make them self authenticate BEFORE establishing a secure communication. By having both the Provider and Consumer redirect to a spot behind a login on both sites it fulfills this requirement without breaking the current model or people's brains. Making something simpler for the sake of simplicity is simply not a compelling argument against requiring habeas corpus at each end. I think too many people are trying to adjust the model instead of the implementation. The model is fine once you can prove (on each end) that it is the same user. Not caring what your login is on the consumer? What does that even mean? Either the redirect url is publicly accessible or it requires a login. I don't need to know WHO you are or care if you are logged in or not, but nothing is going to happen until you prove that you are who you are trying to associate with. This also leaves sites able to craft their redirect urls to contain either unique paths or unique tokens or both without breaking the protocol or damaging the current information exchange model. I still favor a solution that doesn't add or take away anything from the current model. Basically a protocol that reorders passing information to occur after user authentication and tightens rules on where redirects point. On Apr 25, 12:12 pm, Josh Roesslein jroessl...@gmail.com wrote: We don't really need the user to be logged into the consumer to generate our token. The service provider should not care what our login is on the consumer. All it cares about is authorizing a consumer access to our data. We log into the provider and authorize the creation of an access token for the consumer. We then visit this consumer and hand over our token (either manually for desktop apps or by being redirect
[oauth] Re: OAuth Security Advisory
Yeah, I have that at my bank and it sucks all kinds of hell. Thank god I can just Google my mother's maiden name to reset my password when that fails. If a system is designed to work only by relying upon people to not be stupid it will fail. You can't outwit a fool; only fools try. I really need to finish my post on this. It has pictures and everything. Should clear up some confusion people might have. I am not saying that your method is forever flawed, but why change OAuth when it works just fine? Remember, the problem we are facing is still theoretical and the solution I proposed doesn't break anyones current or past work or understanding. On Apr 25, 1:33 pm, Josh Roesslein jroessl...@gmail.com wrote: The only place that a phishing attack would occur in the signed authorization proposal is the authorization URL. An attacker could lure an user to click on a link that directs the user to a clone of the provider and steal the users credentials when logging in. The best way to prevent this is users being careful to check the address bar and making sure the site they are at is indeed the provider's site. Another layer that can help prevent this is by using images that are displayed on the provider's site during login. Some banks use this during login. You first give your username and hit enter. Next the bank shows an image you set when you signed up. You verifty this is the right image and provide your password. This isn't really something oauth should mandate. It is up to the provider to add this layer of security on their own. On Sat, Apr 25, 2009 at 3:24 PM, Brian Eaton bea...@google.com wrote: On Sat, Apr 25, 2009 at 1:11 PM, J. Adam Moore jadammo...@gmail.com wrote: The problem itself is REALLY specific: Phishing. Like fish in a barrel phishing. The solution is to take away their bullets, and is not to try and harden the barrels or educate the fish to dodge bullets. The problem is very similar to phishing, in that it requires some element of social engineering to exploit. However, the current protocol allows a phishing attack where everything the user sees is completely in context and true. The session fixation vulnerability allows perfect phishing. I just reread the protocol you proposed above, and I'm pretty sure it doesn't actually fix the session fixation attack. You need some kind of a callback token passed through the user's browser back to the consumer. (If you were including that, sorry, I missed it.) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] auth header being truncated when return characters are used?
hi folks, I'm not totally sure the best place to ask this question is, but I ran into an issue with OAuth headers that is a bit odd. The oauth library I'm using (oauth-php) creates the Oauth Authorization header to look something like this: Authorization: OAuth realm=, oauth_signature_method=HMAC-SHA1, oauth_signature=b9R%2BMtCpVKhdJ46kOoWatBsbslE%3D, oauth_nonce=49a19dcac9edc, oauth_timestamp=1235328458, oauth_token=, oauth_consumer_key=2rb5KiLWvCDvQjn8HBALw, oauth_version=1.0 this is being called against an nginx webserver, which truncates anything including and after the first return character (ie, it only passes through 'OAuth realm=,'). If I change oauth-php to not insert a return character, nginx passes the full header through. so this raises a few questions: * the oauth spec example shows new line characters: http://oauth.net/core/1.0/#auth_header * I couldn't find anything in the HTTP 1.1 spec that says if newlines are allowed or not * is their a bug in nginx? * the ruby-oauth library does not use a return character when creating the auth header, and it works just fine when going through nginx. and the big one is I'm doing something wrong? After all, I know many people use nginx but I couldnt' find anything about an issue with OAuth and nginx, so it is definitely possible that Im doing something wrong. any feedback would be greatly appreciated. thanks! Adam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: auth header being truncated when return characters are used?
Hi mark! thanks for the quick response. I had previously found the passage from the specs that you highlighted, but I interpreted it differently in that it says 'header field' and did not specify value...but it sort of does right below that plus this reference seals it for me: HTTP/1.1 header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream. LWS= [CRLF] 1*( SP | HT ) from: http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html Mark, I tried your suggestions and it didn't work. I stripped out all sorts of stuff from the nginx config (this is nginx/0.6.34 btw), including any proxy or header modifications, ssl, compression, etc, and it still fails to recognize a multiline header value. So at this point it sounds like a bug with nginx, but in the short term mark would you be willing to remove the ', \n' and just leave it as ', '? I did that in my local copy, so I should be all set, but perhaps that will help others out? I'm surprised this hasn't come up before. Still makes me wonder if I'm missing anything, but that is looking less and less likely. I'll go ahead and file a bug report with nginx. Thanks again Mark for your help! adam On Feb 22, 4:01 pm, Marc Worrell ma...@pobox.com wrote: Hi Adam, On further investigation, could you try with a CRLF in the header? I see that in the code we use a \n and not \r\n as the http spec requires. Can you see if a \r\n makes nginx accept the header correctly? Thanks for your testing, - Marc Worrell On 23 feb 2009, at 00:54, Marc Worrell wrote: Hi Adam, The HTTP spec states clearly that header fields can be extended over multiple lines. Seehttp://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 Quote from the first paragraph in section 4.2: Header fields can be extended over multiple lines by preceding each extra line with at least one SP or HT. So when nginx doesn't pass the multi line authorization header field correctly then I would assume it is a bug in nginx. - Marc Worrell --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
