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 >> <mailto:bcampbell=40pingidentity....@dmarc.ietf.org>> wrote: >> >> >> >> On Sat, Dec 12, 2020 at 1:22 AM Vladimir Dzhuvinov >> <vladi...@connect2id.com <mailto: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 >>> <mailto: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 >>>> <mailto: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 >>>> <mailto: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 >>>>> <mailto: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 >>>>> >>>>> <https://datatracker.ietf.org/doc/draft-ietf-oauth-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 >>>>> <mailto: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 >>>>>> <http://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 >>>>> >>>>> <http://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 >>>>> >>>>> <http://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 <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >> >> -- >> Vladimir Dzhuvinov >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto: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 <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
