Re: [OAUTH-WG] Section 10.1 (Client authentication)
Hi Eran, I would suggest to change it to SHOULD and add a reference to https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections 3.7 and 5.2.3. regards, Torsten. Eran Hammer-Lahav e...@hueniverse.com schrieb: It's a pointless MUST given how undefined the requirements are. It will only be understood by security experts and they don't really need it. At a minimum, it needs some examples. EHL From: Torsten Lodderstedt tors...@lodderstedt.net Date: Wed, 1 Jun 2011 00:53:37 -0700 To: Eran Hammer-lahav e...@hueniverse.com, OAuth WG oauth@ietf.org Subject: Section 10.1 (Client authentication) Hi Eran, would you please add the following sentence (which was contained in the original security considerations text) to the second paragraph of section 1.0.1? Alternatively, authorization servers MUST utilize other means than client authentication to achieve their security objectives. I think it's important to state that authorization server should consider alternative way to validate the client identity if secrets cannot be used. The security threat document also suggest some. regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 16 Security Considerations additions
Reworded to modify the text around secret and some additional info on redirect-uri (with some input from Shane Weaden) and adding state in dynamic redirect-uri (with input from Torsten) CSRF Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth Protected Resources without the consent of the User. The state parameter should be used to mitigate against CSRF attacks, particularly for login CSRF attacks. CSRF attacks against a client's redirect URI allow an attacker to inject their own authorization code (or access token for implicit grant flow). This may result in the client using an access token associated with the attackers account rather than the victims. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects. It is strongly RECOMMENDED that the client sends the state parameter with authorization requests to the authorization server. The state parameter MUST be non-guessable and the client MUST be capable of keeping it in a location accessible only by the client or the user agent (i.e., protected by same-origin policy). e.g.: DOM variable (protected by _javascript_ or other DOM-binding language's enforcement of SOP), HTTP cookie, HTML5 client-side storage, etc. The authorization server will send it in the response when redirecting the user to back to the client which MUST then validate the state parameter matches on the response. Use of the state parameter by a client protects against this style of attack as the attacker cannot know the state parameter associated with the victims browser session at the client. While sending the state parameter is the preferred mechanism for linking the client to the authorization requests and callbacks, a state parameter (s) embedded into the redirect uri could be used for the same purpose. A prerequisite is that the authorization server's uri validation policy must allow for dynamic uri query parts. Clickjacking Clickjacking is the process of tricking users into revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages. In more detail, a malicious site loads the target site in a transparent iframe overlaid on top of a set of dummy buttons which are carefully constructed to be placed directly under important buttons on the target site. When a user clicks a visible button, they are actually clicking a button (such as an Authorize button) on the hidden page. To prevent clickjacking (and phishing attacks), native applications SHOULD use external browsers instead of embedding browsers in an iFrame when requesting end-user authorization. For newer browsers, avoidance of iFrames can be enforced server side by using the X-FRAME-OPTION header. This header can have two values, deny and sameorigin, which will block any framing or framing by sites with a different origin, respectively. For older browsers, javascript framebusting techniques can be used but may not be effective in all browsers. Regards Eran Hammer-Lahav e...@hueniverse.com wrote on 04/07/2011 20:02:02: From: Eran Hammer-Lahav e...@hueniverse.com To: Mark Mcgloin/Ireland/IBM@IBMIE, Torsten Lodderstedt tors...@lodderstedt.net Cc: oauth@ietf.org oauth@ietf.org Date: 04/07/2011 20:01 Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions This needs to be reworked to reflect reality. The state value must be shared with the resource owner's browser and authorization server, so it is not really a secret known only to the client… EHL From: Mark Mcgloin mark.mcgl...@ie.ibm.com Date: Wed, 1 Jun 2011 11:28:33 -0700 To: Torsten Lodderstedt tors...@lodderstedt.net Cc: oauth@ietf.org oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions Hi Torsten It was implicit that the state parameter would be secret and not guessable but that it probably worth spelling out, as you and Breno state. Here is a modified version CSRF Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth Protected Resources without the consent of the User. The state parameter should be used to mitigate against CSRF attacks, particularly for login CSRF attacks. It is strongly RECOMMENDED that the client sends the state parameter with authorization requests to the authorization server. The state parameter MUST be non-guessable and MUST be a secret only accessible to the client. The authorization server will send it in the response when redirecting the user to back to the client which MUST then validate the state parameter matches on the response. Regards Mark Torsten Lodderstedt
[OAUTH-WG] Concerns about Implicit Grant flow
Hello! Foursquare recently encountered a scary example of a client accidentally leaking user tokens as part of the implicit grant flow. It turns out the official Tweet this button provided by twitter grabs the URL, including fragment, at the time of page load, before the client's Javascript has had a chance to elide the access_token hash value. And it's easy to imagine lots of other sharing and analytics tools could be similarly aggressive in transmitting hash values outside of the page. We've thought a lot about what to do about this, short of disabling the flow entirely. One thing that seems viable is to make the access token in this flow actually a one-time use token. The requesting page would then make a JSONP request exchanging the one-time use token for a permanent token that is never visible in the URL. Has this come up? Have you had any feedback from other implementors? We're not excited about such a blatant deviation from the spec, but we're not sure what else to do. Cheers, Kushal ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Concerns about Implicit Grant flow
You can still use the access code (web server) flow within a JavaScript application, just without a reliable client secret. The point of the implicit flow was to save a roundtrip to the server for light clients with limited lifespans, and it's a tradeoff between security, ease of implementation, and performance. -- Justin On Wed, 2011-07-06 at 16:08 -0400, Kushal Dave wrote: Hello! Foursquare recently encountered a scary example of a client accidentally leaking user tokens as part of the implicit grant flow. It turns out the official Tweet this button provided by twitter grabs the URL, including fragment, at the time of page load, before the client's Javascript has had a chance to elide the access_token hash value. And it's easy to imagine lots of other sharing and analytics tools could be similarly aggressive in transmitting hash values outside of the page. We've thought a lot about what to do about this, short of disabling the flow entirely. One thing that seems viable is to make the access token in this flow actually a one-time use token. The requesting page would then make a JSONP request exchanging the one-time use token for a permanent token that is never visible in the URL. Has this come up? Have you had any feedback from other implementors? We're not excited about such a blatant deviation from the spec, but we're not sure what else to do. Cheers, Kushal ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Concerns about Implicit Grant flow
Correct me if i'm wrong, this case is handled by the nonce and time-stamp values ? On 6 July 2011 22:31, Justin Richer jric...@mitre.org wrote: You can still use the access code (web server) flow within a JavaScript application, just without a reliable client secret. The point of the implicit flow was to save a roundtrip to the server for light clients with limited lifespans, and it's a tradeoff between security, ease of implementation, and performance. -- Justin On Wed, 2011-07-06 at 16:08 -0400, Kushal Dave wrote: Hello! Foursquare recently encountered a scary example of a client accidentally leaking user tokens as part of the implicit grant flow. It turns out the official Tweet this button provided by twitter grabs the URL, including fragment, at the time of page load, before the client's Javascript has had a chance to elide the access_token hash value. And it's easy to imagine lots of other sharing and analytics tools could be similarly aggressive in transmitting hash values outside of the page. We've thought a lot about what to do about this, short of disabling the flow entirely. One thing that seems viable is to make the access token in this flow actually a one-time use token. The requesting page would then make a JSONP request exchanging the one-time use token for a permanent token that is never visible in the URL. Has this come up? Have you had any feedback from other implementors? We're not excited about such a blatant deviation from the spec, but we're not sure what else to do. Cheers, Kushal ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Concerns about Implicit Grant flow
On Wed, Jul 6, 2011 at 1:31 PM, Justin Richer jric...@mitre.org wrote: You can still use the access code (web server) flow within a JavaScript application, just without a reliable client secret. The point of the implicit flow was to save a roundtrip to the server for light clients with limited lifespans, and it's a tradeoff between security, ease of implementation, and performance. Yep. Two other options. - give out authorization codes via the user-agent flow. We've implemented a variation of this based on HTML5 and window.postMessage. - use a fixed callback URL for the user-agent flow. Make sure that fixed callback URL does not run random bits of script. Then have that fixed callback URL use javascript to convey the token to other pages on the same origin. It's a bad idea to use the user-agent flow without a specific whitelist of callback URLs which can receive the token. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Concerns about Implicit Grant flow
- give out authorization codes via the user-agent flow. We've implemented a variation of this based on HTML5 and window.postMessage. Caveat: This will run you off-spec. - use a fixed callback URL for the user-agent flow. Make sure that fixed callback URL does not run random bits of script. Then have that fixed callback URL use javascript to convey the token to other pages on the same origin. It's a bad idea to use the user-agent flow without a specific whitelist of callback URLs which can receive the token. Brian's nailed it here. The best way to use this flow is to control the landing page as much as possible. -- Justin ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Example tokens
Are the tokens used in the examples long enough? I don't want the examples to demonstrate poor choice of byte count. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Concerns about Implicit Grant flow
These are all good ways to mitigate the issue, but they don't solve it. If you are running third-party scripts on the redirection URI page, all bets are off as to who is going to end up with the access token, authorization code, etc. It is pretty bad security to run any kind of third party code on your login page, which in many cases, the redirection page is (Facebook connect, etc.). The callback whitelist doesn't really add any protection against this specific leakage given that no large provider has the resources to scan every redirection URI page for third-party scripts, analyze them, and block such URIs (and do this continuously to monitor changes). What these alternatives do is reduce the likelihood of a leaked credential being abused, but they are still going to be exposed if all you change is the flow, not the redirection URI page. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Eaton Sent: Wednesday, July 06, 2011 1:42 PM To: Justin Richer Cc: Kushal Dave; oauth@ietf.org Subject: Re: [OAUTH-WG] Concerns about Implicit Grant flow On Wed, Jul 6, 2011 at 1:31 PM, Justin Richer jric...@mitre.orgmailto:jric...@mitre.org wrote: You can still use the access code (web server) flow within a JavaScript application, just without a reliable client secret. The point of the implicit flow was to save a roundtrip to the server for light clients with limited lifespans, and it's a tradeoff between security, ease of implementation, and performance. Yep. Two other options. - give out authorization codes via the user-agent flow. We've implemented a variation of this based on HTML5 and window.postMessage. - use a fixed callback URL for the user-agent flow. Make sure that fixed callback URL does not run random bits of script. Then have that fixed callback URL use javascript to convey the token to other pages on the same origin. It's a bad idea to use the user-agent flow without a specific whitelist of callback URLs which can receive the token. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Concerns about Implicit Grant flow
What triggers this flow? If you are using the authorization endpoint with a different response_type, it would be helpful if you shared that with the wg as currently, that's simply not allowed (the values are not extensible). I am going to change that in -17, but based on the requirement presented by Paul Tarjan. Additional use cases would be extremely helpful. Also, I'd hate to see Google being the first to violate the protocol in that scale. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Eaton Sent: Wednesday, July 06, 2011 1:42 PM - give out authorization codes via the user-agent flow. We've implemented a variation of this based on HTML5 and window.postMessage. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Example tokens
So on the 128-bit note, the examples could probably be a bit shorter, 22 characters would give somewhat more than 128 bits of randomness. But to EHL's original question, the examples (currently 7-12 characters) should probably be longer. On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb oleg_g...@yahoo.com wrote: log2(64^27)=162 bits Looks good. For comparison, 128-bit entropy for a key in symmetric encryption used by SSL is considered as strong. I'm assuming that all those 162 bits are generated by a good randomizer. - Original Message From: Brian Campbell bcampb...@pingidentity.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: OAuth WG oauth@ietf.org Sent: Wed, July 6, 2011 4:06:29 PM Subject: Re: [OAUTH-WG] Example tokens If I've done the math correctly, 27 characters would give you a little more than 20 bytes worth of randomness (assuming your are using random alphanumeric characters or base64url encoded bytes). 20 bytes is something you see as a SHOULD type minimum length in other protocols for random identifiers. Not sure if that's sufficient reasoning but it's what I can come up with. On Wed, Jul 6, 2011 at 4:40 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Are the tokens used in the examples long enough? I don't want the examples to demonstrate poor choice of byte count. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Example tokens
Does that apply to access tokens, refresh tokens, and authorization codes? I can try squeezing in 22 characters. EHL -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Wednesday, July 06, 2011 8:46 PM To: Oleg Gryb Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] Example tokens So on the 128-bit note, the examples could probably be a bit shorter, 22 characters would give somewhat more than 128 bits of randomness. But to EHL's original question, the examples (currently 7-12 characters) should probably be longer. On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb oleg_g...@yahoo.com wrote: log2(64^27)=162 bits Looks good. For comparison, 128-bit entropy for a key in symmetric encryption used by SSL is considered as strong. I'm assuming that all those 162 bits are generated by a good randomizer. - Original Message From: Brian Campbell bcampb...@pingidentity.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: OAuth WG oauth@ietf.org Sent: Wed, July 6, 2011 4:06:29 PM Subject: Re: [OAUTH-WG] Example tokens If I've done the math correctly, 27 characters would give you a little more than 20 bytes worth of randomness (assuming your are using random alphanumeric characters or base64url encoded bytes). 20 bytes is something you see as a SHOULD type minimum length in other protocols for random identifiers. Not sure if that's sufficient reasoning but it's what I can come up with. On Wed, Jul 6, 2011 at 4:40 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Are the tokens used in the examples long enough? I don't want the examples to demonstrate poor choice of byte count. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Example tokens
Yes, I think it would apply to all three (in cases where the value is some reference). I feel like a refresh token should be a little longer but I don't know if that feeling would actually hold up when doing a real threat model analysis. On Wed, Jul 6, 2011 at 9:53 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Does that apply to access tokens, refresh tokens, and authorization codes? I can try squeezing in 22 characters. EHL -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Wednesday, July 06, 2011 8:46 PM To: Oleg Gryb Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] Example tokens So on the 128-bit note, the examples could probably be a bit shorter, 22 characters would give somewhat more than 128 bits of randomness. But to EHL's original question, the examples (currently 7-12 characters) should probably be longer. On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb oleg_g...@yahoo.com wrote: log2(64^27)=162 bits Looks good. For comparison, 128-bit entropy for a key in symmetric encryption used by SSL is considered as strong. I'm assuming that all those 162 bits are generated by a good randomizer. - Original Message From: Brian Campbell bcampb...@pingidentity.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: OAuth WG oauth@ietf.org Sent: Wed, July 6, 2011 4:06:29 PM Subject: Re: [OAUTH-WG] Example tokens If I've done the math correctly, 27 characters would give you a little more than 20 bytes worth of randomness (assuming your are using random alphanumeric characters or base64url encoded bytes). 20 bytes is something you see as a SHOULD type minimum length in other protocols for random identifiers. Not sure if that's sufficient reasoning but it's what I can come up with. On Wed, Jul 6, 2011 at 4:40 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Are the tokens used in the examples long enough? I don't want the examples to demonstrate poor choice of byte count. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Example tokens
Are the tokens used in the examples long enough? I don't want the examples to demonstrate poor choice of byte count. No. I found the following example values in draft 16. Client secret: gX1fBat3bV (10 chars, 60 bits) Code: i1WsRn1uB1 (10 chars, 60 bits) Access token: SlAV32hkKG (10 chars, 60 bits) Access token: FJQbwq9 ( 7 chars, 48 bits) Access token: 7Fjfp0ZBr1KtDRbnfVdmIw (22 chars, 132 bits, bearer token) Access token: h480djs93hd8(12 chars, 72 bits, MAC id) Refresh token: 8xLOxBtZp8 (10 chars, 60 bits) Refresh token: n4E9O119d ( 9 chars, 54 bits) User password: A3ddj3w ( 7 chars, ? bits, user-chosen) 128 bits of entropy would be a good choice for most values. That is equivalent to 22 random base64 chars, as per longest example above. That is a minimum mentioned in draft-lodderstedt-oauth-security. Using 22-char values throughout the spec probably doesn't harm readability much as most of the examples already wrap over multiple lines (it might even help by wrapping more parameter names to the start of lines). The example user password is long enough. Curiously the secrets, codes, and tokens all look like base64-encoded values - but almost none are actually valid base64 (the last char leaves non-zero bits in a final partial byte). For instance, i1WsRn1uB1 should be i1WsRn1uBw (last char changes) to be a base64-encoding of 7 bytes. I suggest using four 22-char values for the four quantities (client secret, code, access token, refresh token) consistently throughout the spec. Here are four: 2YotnFZFEjr1zCsicMWpAA tGzv3JOkF0XG5Qx2TlKWIA 7Fjfp0ZBr1KtDRbnfVdmIw SplxlOBeZQQYbYS6WxSbIA -- James Manger smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Example tokens
Fantastic! From: Manger, James H [mailto:james.h.man...@team.telstra.com] Sent: Wednesday, July 06, 2011 9:11 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Example tokens Are the tokens used in the examples long enough? I don't want the examples to demonstrate poor choice of byte count. No. I found the following example values in draft 16. Client secret: gX1fBat3bV (10 chars, 60 bits) Code: i1WsRn1uB1 (10 chars, 60 bits) Access token: SlAV32hkKG (10 chars, 60 bits) Access token: FJQbwq9 ( 7 chars, 48 bits) Access token: 7Fjfp0ZBr1KtDRbnfVdmIw (22 chars, 132 bits, bearer token) Access token: h480djs93hd8(12 chars, 72 bits, MAC id) Refresh token: 8xLOxBtZp8 (10 chars, 60 bits) Refresh token: n4E9O119d ( 9 chars, 54 bits) User password: A3ddj3w ( 7 chars, ? bits, user-chosen) 128 bits of entropy would be a good choice for most values. That is equivalent to 22 random base64 chars, as per longest example above. That is a minimum mentioned in draft-lodderstedt-oauth-security. Using 22-char values throughout the spec probably doesn't harm readability much as most of the examples already wrap over multiple lines (it might even help by wrapping more parameter names to the start of lines). The example user password is long enough. Curiously the secrets, codes, and tokens all look like base64-encoded values - but almost none are actually valid base64 (the last char leaves non-zero bits in a final partial byte). For instance, i1WsRn1uB1 should be i1WsRn1uBw (last char changes) to be a base64-encoding of 7 bytes. I suggest using four 22-char values for the four quantities (client secret, code, access token, refresh token) consistently throughout the spec. Here are four: 2YotnFZFEjr1zCsicMWpAA tGzv3JOkF0XG5Qx2TlKWIA 7Fjfp0ZBr1KtDRbnfVdmIw SplxlOBeZQQYbYS6WxSbIA -- James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
