I don't share the same sentiment about at_hash being a pain, we already have the tools on the server. And browser side it's a matter of 15loc using webcrypto api since, well, the JWS algorithm support there is limited to the simple ones ending with the bitsize needed anyway.
Nevertheless if we're saying sha256 of the key thumbprint is fine i don't see why we wouldn't be able to do the same for new AT hash property (no longer called at_hash i assume). But if XSS is game over, let's not bother with trying to patch one particular scenario with a hash. - Filip Odesláno z iPhonu > 19. 12. 2020 v 7:00, Vladimir Dzhuvinov <vladi...@connect2id.com>: > > > Thank you Justin for this honest account of your experience with DPoP. > > To at_hash or not is maybe not solved yet, but at least it's clear there's > little enthusiasm about the OIDC style at_hash :) > > Vladimir > > On 15/12/2020 18:40, Justin Richer wrote: >> I went and implemented this proposal of including a token hash in both an AS >> (java) and client (javascript) on a system that was already using DPoP and >> OpenID Connect. What I did there was just use the existing code we had on >> the AS-side to calculate the “at_hash” in the ID Token from OIDC, which I >> also used to verify on the token-accepting portions. I had to implement the >> function on the client side, but that was only a couple lines using a crypto >> library to do the heavy hash lift. >> >> The most annoying part is dealing with the hash variability in the OIDC >> method. As Brian points out, this isn’t particularly robust, and it depends >> on the wrapper being JOSE. That’s not a huge deal because DPoP uses JOSE for >> its wrapper, but it’s still extra code to deal with — to the point where I >> just hardcoded the hash algorithm in my test so that I didn’t have to put >> together the switch case over the algorithm. >> >> So in at least my own experience, the addition is minimal on both client and >> server, and whatever we would decide for the hash algorithm would be simple >> enough to manage. I have a slight preference for just picking something like >> SHA256 and calling it a day (and defining other hashes in the future when >> SHA256 is broken), but that’s not a hill I care to die on. >> >> — Justin >> >>> On Dec 14, 2020, at 4:27 PM, Brian Campbell >>> <bcampbell=40pingidentity....@dmarc.ietf.org> wrote: >>> >>> >>> >>> On Sat, Dec 12, 2020 at 1:22 AM Vladimir Dzhuvinov >>> <vladi...@connect2id.com> wrote: >>>> If the current DPoP has code complexity "X", the relative additional >>>> complexity to include access token hashes doesn't seem like very much. An >>>> app choosing DPoP means accepting the code complexity that comes with >>>> dealing with keys, composing the signing inputs for the proofs, signing, >>>> the necessary changes to the token and RS requests. On the other hand, for >>>> some people that additional access token hash may become the straw that >>>> breaks the camel's back, causing them to quit their jobs developing web >>>> apps and never look back :) >>>> >>> Yeah, the relative additional complexity to include an access token hash >>> maybe isn't too much but it's also not not nothing. It's a different kind >>> of operation than the other things you listed (yes, I know there's a hash >>> as part of the signing but it's abstracted away from the developer in most >>> cases) and something that can be quite difficult to troubleshoot when >>> different parties arrive at different hash values. Hence my lack of >>> conviction on this one way or the other. >>> >>>> >>>> Have you thought about letting deployments decide about the access token >>>> hash? To say look, there is also the option to bind an access token to the >>>> DPoP proof, the security benefits can be such an such, and this is how it >>>> can be done. >>>> >>>> What I don't like about that proposal: >>>> >>>> It will complicate the spec >>>> >>>> The current spec doesn't require implementers / deployments to make any >>>> decisions, apart from adopt / not DPoP (okay, also choose a JWS alg) - >>>> which is actually a great feature to have >>> >>> I also don't like it for basically the same reasons. I've definitely aimed >>> to keep it simple from that perspective of not having a lot of optionality >>> or switches. It is a nice feature to have, when possible. >>> >>> >>>> Vladimir >>>> >>>> >>>> >>>> On 12/12/2020 01:58, Brian Campbell wrote: >>>>> Any type of client could use DPoP and (presumably) benefit from >>>>> sender-constrained access tokens. So yeah, adding complexity specifically >>>>> for browser-based applications (that only mitigates one variation of the >>>>> attacks possible with XSS anyway) has 'cost' impact to those clients as >>>>> well. And should be considered in the cost/benefit. Including the AT hash >>>>> isn't terribly complicated but it's not trivial either. I'm honestly >>>>> still unsure but am leaning towards it not being worth adding. >>>>> >>>>> On Fri, Dec 11, 2020 at 2:14 AM Philippe De Ryck >>>>> <phili...@pragmaticwebsecurity.com> wrote: >>>>>> The scenario you describe here is realistic in browser-based apps with >>>>>> XSS vulnerabilities, but it is pretty complex. Since there are worse >>>>>> problems when XSS happens, it’s hard to say whether DPoP should mitigate >>>>>> this. >>>>>> >>>>>> I’m wondering what other types of clients would benefit from using DPoP >>>>>> for access tokens? Mobile apps? Clients using a Client Credentials grant? >>>>>> >>>>>> How are they impacted by any change made specifically for browser-based >>>>>> applications? >>>>>> >>>>>> Philippe >>>>>> >>>>>> >>>>>>> On 9 Dec 2020, at 23:57, Brian Campbell <bcampb...@pingidentity.com> >>>>>>> wrote: >>>>>>> >>>>>>> Thanks Philippe, I very much concur with your line of reasoning and the >>>>>>> important considerations. The scenario I was thinking of is: browser >>>>>>> based client where XSS is used to exfiltrate the refresh token along >>>>>>> with pre-computed proofs that would allow for the RT to be exchanged >>>>>>> for new access tokens and also pre-computed proofs that would work with >>>>>>> those access tokens for resource access. With the pre-computed proofs >>>>>>> that would allow prolonged (as long as the RT is valid) access to >>>>>>> protected resources even when the victim is offline. Is that a concrete >>>>>>> attack scenario? I mean, kind of. It's pretty convoluted/complex. And >>>>>>> while an access token hash would reign it in somewhat (ATs obtained >>>>>>> from the stolen RT wouldn't be usable) it's hard to say if the cost is >>>>>>> worth the benefit. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2020 at 11:47 PM Philippe De Ryck >>>>>>> <phili...@pragmaticwebsecurity.com> wrote: >>>>>>>> Yeah, browser-based apps are pure fun, aren’t they? :) >>>>>>>> >>>>>>>> The reason I covered a couple of (pessimistic) XSS scenarios is that >>>>>>>> the discussion started with an assumption that the attacker already >>>>>>>> successfully exploited an XSS vulnerability. I pointed out how, at >>>>>>>> that point, finetuning DPoP proof contents will have little to no >>>>>>>> effect to stop an attack. I believe it is important to make this very >>>>>>>> clear, to avoid people turning to DPoP as a security mechanism for >>>>>>>> browser-based applications. >>>>>>>> >>>>>>>> >>>>>>>> Specifically to your question on including the hash in the proof, I >>>>>>>> think these considerations are important: >>>>>>>> >>>>>>>> 1. Does the inclusion of the AT hash stop a concrete attack scenario? >>>>>>>> 2. Is the “cost” (implementation, getting it right, …) worth the >>>>>>>> benefits? >>>>>>>> >>>>>>>> >>>>>>>> Here’s my view on these considerations (specifically for browser-based >>>>>>>> apps, not for other types of applications): >>>>>>>> >>>>>>>> 1. The proof precomputation attack is already quite complex, and short >>>>>>>> access token lifetimes already reduce the window of attack. If the >>>>>>>> attacker can steal a future AT, they could also precompute new proofs >>>>>>>> then. >>>>>>>> 2. For browser-based apps, it seems that doing this complicates the >>>>>>>> implementation, without adding much benefit. Of course, libraries >>>>>>>> could handle this, which significantly reduces the cost. >>>>>>>> >>>>>>>> >>>>>>>> Note that these comments are specifically to complicating the spec and >>>>>>>> implementation. DPoP’s capabilities of using sender-constrained access >>>>>>>> tokens are still useful to counter various other scenarios (e.g., >>>>>>>> middleboxes or APIs abusing access tokens). If other applications >>>>>>>> would significantly benefit from having the hash in the proof, I’m all >>>>>>>> for it. >>>>>>>> >>>>>>>> On a final note, I would be happy to help clear up the details on >>>>>>>> web-based threats and defenses if necessary. >>>>>>>> >>>>>>>> — >>>>>>>> Pragmatic Web Security >>>>>>>> Security for developers >>>>>>>> https://pragmaticwebsecurity.com/ >>>>>>>> >>>>>>>> >>>>>>>>> On 8 Dec 2020, at 22:47, Brian Campbell <bcampb...@pingidentity.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Danial recently added some text to the working copy of the draft with >>>>>>>>> https://github.com/danielfett/draft-dpop/commit/f4b42058 that I think >>>>>>>>> aims to better convey the "nutshell: XSS = Game over" sentiment and >>>>>>>>> maybe dissuade folks from looking to DPoP as a cure-all for browser >>>>>>>>> based applications. Admittedly a lot of the initial impetus behind >>>>>>>>> producing the draft in the first place was born out of discussions >>>>>>>>> around browser based apps. But it's neither specific to browser based >>>>>>>>> apps nor a panacea for them. I hope the language in the document and >>>>>>>>> how it's recently been presented is reflective of that reality. >>>>>>>>> >>>>>>>>> The more specific discussions/recommendations around in-browser apps >>>>>>>>> are valuable (if somewhat over my head) but might be more appropriate >>>>>>>>> in the OAuth 2.0 for Browser-Based Apps draft. >>>>>>>>> >>>>>>>>> With respect to the contents of the DPoP draft, I am still keen to >>>>>>>>> try and flush out some consensus around the question posed in the >>>>>>>>> start of this thread, which is effectively whether or not to include >>>>>>>>> a hash of the access token in the proof. Acknowledging that "XSS = >>>>>>>>> Game over" does sort of evoke a tendency to not even bother with such >>>>>>>>> incremental protections (what I've tried to humorously coin as "XSS >>>>>>>>> Nihilism" with no success). And as such, I do think that leaving it >>>>>>>>> how it is (no AT hash in the proof) is not unreasonable. But, as >>>>>>>>> Filip previously articulated, including the AT hash in the proof >>>>>>>>> would prevent potentially prolonged access to protected resources >>>>>>>>> even when the victim is offline. And that seems maybe worthwhile to >>>>>>>>> have in the protocol, given that it's not a huge change to the spec. >>>>>>>>> But it's a trade-off either way and I'm personally on the fence about >>>>>>>>> it. >>>>>>>>> >>>>>>>>> Including an RT hash in the proof seems more niche. Best I can tell, >>>>>>>>> it would guard against prolonged offline access to protected >>>>>>>>> resources when access tokens are bearer and the RT was DPoP-bound and >>>>>>>>> also gets rotated. The trade-off there seems less worth it (I think >>>>>>>>> an RT hash would be more awkward in the protocol too). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Dec 4, 2020 at 5:40 AM Philippe De Ryck >>>>>>>>> <phili...@pragmaticwebsecurity.com> wrote: >>>>>>>>>> >>>>>>>>>>> The suggestion to use a web worker to ensure that proofs cannot be >>>>>>>>>>> pre-computed is a good one I think. (You could also use a sandboxed >>>>>>>>>>> iframe for a separate sub/sibling-domain - dpop.example.com). >>>>>>>>>> >>>>>>>>>> An iframe with a different origin would also work (not really >>>>>>>>>> sandboxing, as that implies the use of the sandbox attribute to >>>>>>>>>> enforce behavioral restrictions). The downside of an iframe is the >>>>>>>>>> need to host additional HTML, vs a script file for the worker, but >>>>>>>>>> the effect is indeed the same. >>>>>>>>>> >>>>>>>>>>> For scenario 4, I think this only works if the attacker can >>>>>>>>>>> trick/spoof the AS into using their redirect_uri? Otherwise the AC >>>>>>>>>>> will go to the legitimate app which will reject it due to >>>>>>>>>>> mismatched state/PKCE. Or are you thinking of XSS on the >>>>>>>>>>> redirect_uri itself? I think probably a good practice is that the >>>>>>>>>>> target of a redirect_uri should be a very minimal and locked down >>>>>>>>>>> page to avoid this kind of possibility. (Again, using a separate >>>>>>>>>>> sub-domain to handle tokens and DPoP seems like a good idea). >>>>>>>>>> >>>>>>>>>> My original thought was to use a silent flow with Web Messaging. The >>>>>>>>>> scenario would go as follows: >>>>>>>>>> >>>>>>>>>> 1. Setup a Web Messaging listener to receive the incoming code >>>>>>>>>> 2. Create a hidden iframe with the DOM APIs >>>>>>>>>> 3. Create an authorization request such as >>>>>>>>>> “/authorize?response_type=code&client_id=...&redirect_uri=https%3A%2F%example.com&state=...&code_challenge=7-ffnU1EzHtMfxOAdlkp_WixnAM_z9tMh3JxgjazXAk&code_challenge_method=S256&prompt=none&response_mode=web_message” >>>>>>>>>> 4. Load this URL in the iframe, and wait for the result >>>>>>>>>> 5. Retrieve code in the listener, and use PKCE (+ DPoP if needed) to >>>>>>>>>> exchange it for tokens >>>>>>>>>> >>>>>>>>>> This puts the attacker in full control over every aspect of the >>>>>>>>>> flow, so no need to manipulate any of the parameters. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> After your comment, I also believe an attacker can run the same >>>>>>>>>> scenario without the “response_mode=web_message”. This would go as >>>>>>>>>> follows: >>>>>>>>>> >>>>>>>>>> 1. Create a hidden iframe with the DOM APIs >>>>>>>>>> 2. Setup polling to read the URL (this will be possible for >>>>>>>>>> same-origin pages, not for cross-origin pages) >>>>>>>>>> 3. Create an authorization request such as >>>>>>>>>> “/authorize?response_type=code&client_id=...&redirect_uri=https%3A%2F%example.com&state=...&code_challenge=7-ffnU1EzHtMfxOAdlkp_WixnAM_z9tMh3JxgjazXAk&code_challenge_method=S256” >>>>>>>>>> 4. Load this URL in the iframe, and keep polling >>>>>>>>>> 5. Detect the redirect back to the application with the code in the >>>>>>>>>> URL, retrieve code, and use PKCE (+ DPoP if needed) to exchange it >>>>>>>>>> for tokens >>>>>>>>>> >>>>>>>>>> In step 5, the application is likely to also try to exchange the >>>>>>>>>> code. This will fail due to a mismatching PKCE verifier. While >>>>>>>>>> noisy, I don’t think it affects the scenario. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> IMO, the online attack scenario (i.e., proxying malicious requests >>>>>>>>>>> through the victim’s browser) is quite appealing to an attacker, >>>>>>>>>>> despite the apparent inconvenience: >>>>>>>>>>> >>>>>>>>>>> - the victim’s browser may be inside a corporate firewall or VPN, >>>>>>>>>>> allowing the attacker to effectively bypass these restrictions >>>>>>>>>>> - the attacker’s traffic is mixed in with the user’s own requests, >>>>>>>>>>> making them harder to distinguish or to block >>>>>>>>>>> >>>>>>>>>>> Overall, DPoP can only protect against XSS to the same level as >>>>>>>>>>> HttpOnly cookies. This is not nothing, but it means it only >>>>>>>>>>> prevents relatively naive attacks. Given the association of public >>>>>>>>>>> key signatures with strong authentication, people may have >>>>>>>>>>> overinflated expectations if DPoP is pitched as an XSS defence. >>>>>>>>>> >>>>>>>>>> Yes, in the cookie world this is known as “Session Riding”. Having >>>>>>>>>> the worker for token isolation would make it possible to enforce a >>>>>>>>>> coarse-grained policy on outgoing requests to prevent total abuse of >>>>>>>>>> the AT. >>>>>>>>>> >>>>>>>>>> My main concern here is the effort of doing DPoP in a browser versus >>>>>>>>>> the limited gains. It may also give a false sense of security. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> With all this said, I believe that the AS can lock down its >>>>>>>>>> configuration to reduce these attack vectors. A few initial ideas: >>>>>>>>>> >>>>>>>>>> 1. Disable silent flows for SPAs using RT rotation >>>>>>>>>> 2. Use the sec-fetch headers to detect and reject non-silent >>>>>>>>>> iframe-based flows >>>>>>>>>> >>>>>>>>>> For example, an OAuth 2.0 flow in an iframe in Brave/Chrome carries >>>>>>>>>> these headers: >>>>>>>>>> sec-fetch-dest: iframe >>>>>>>>>> sec-fetch-mode: navigate >>>>>>>>>> sec-fetch-site: cross-site >>>>>>>>>> sec-fetch-user: ?1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Philippe >>>>>>>>>> >>>>>>>>> >>>>>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>>>>> privileged material for the sole use of the intended recipient(s). >>>>>>>>> Any review, use, distribution or disclosure by others is strictly >>>>>>>>> prohibited. If you have received this communication in error, please >>>>>>>>> notify the sender immediately by e-mail and delete the message and >>>>>>>>> any file attachments from your computer. Thank you. >>>>>>>> >>>>>>> >>>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>>> privileged material for the sole use of the intended recipient(s). Any >>>>>>> review, use, distribution or disclosure by others is strictly >>>>>>> prohibited. If you have received this communication in error, please >>>>>>> notify the sender immediately by e-mail and delete the message and any >>>>>>> file attachments from your computer. Thank you. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>> privileged material for the sole use of the intended recipient(s). Any >>>>> review, use, distribution or disclosure by others is strictly prohibited. >>>>> If you have received this communication in error, please notify the >>>>> sender immediately by e-mail and delete the message and any file >>>>> attachments from your computer. Thank you. >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> -- >>>> Vladimir Dzhuvinov >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged >>> material for the sole use of the intended recipient(s). Any review, use, >>> distribution or disclosure by others is strictly prohibited. If you have >>> received this communication in error, please notify the sender immediately >>> by e-mail and delete the message and any file attachments from your >>> computer. Thank you._______________________________________________ >>> 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
